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Scope 



The present document specifies the, stage three, Protocol Description of the signalHng interworking between ISDN 
DSSl protocol and SIP based on the concatenation of ES 283 027 [1] with EN 300 899-1 [2]. The concatenation 
method describes only the SIP/ISDN parameter mapping without ISUP procedures. In addition direct inter- working not 
supported by this concatenation of these existing inter- working documents will be described. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 283 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Endorsement of the SIP-ISUP Interworking between the IP 
Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks 
[3GPP TS 29.163 (Release 7), modified]". 

[2] ETSI EN 300 899-1 (VI . 1 .2): "Integrated Services Digital Network (ISDN); Signalling System 

No. 7; Inter working between ISDN User Part (ISUP) version 2 and Digital Subscriber Signalling 
System No. one (DSSl);Part 1: Protocol specification [ITU-T Recommendation Q.699, 
modified]". 

[3] ETSI ES 283 003 (VI. 8.0): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
(Release 7), modified]". 

[4] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[5] ETSI ES 283 003 (V2.5.1): "Telecommunications and Internet converged Services and Protocols 

for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7] , modified] " . 
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[6] ETSI TS 183 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification 
Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification". 

[7] ETSI TS 183 008: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services Terminating Identification 
Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification". 

[8] ETSI TS 183 004: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN) PSTN/ISDN simulation services: Communication Diversion 
(CDIV); Protocol specification". 

[9] ETSI TS 183 005: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONE); Protocol 
specification" . 

[10] ETSI TS 183 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Signalling Control Protocol; Communication HOLD 
(HOLD) PSTN/ISDN simulation services; Protocol specification". 

[11] ETSI ETS 300 052-1 : "Integrated Services Digital Network (ISDN); Multiple Subscriber Number 

(MSN) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[12] ETSI ETS 300 055-1 : "Integrated Services Digital Network (ISDN); Terminal Portability (TP) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[13] ETSI ETS 300 058-1 : "Integrated Services Digital Network (ISDN); Call Waiting (CW) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[14] ETSI ETS 300 061-1 : "Integrated Services Digital Network (ISDN); Subaddressing (SUB) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[15] ETSI ETS 300 064-1 : "Integrated Services Digital Network (ISDN); Direct Dialling In (DDI) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[16] ETSI ETS 300 092-1 : "Integrated Services Digital Network (ISDN); Calling Line Identification 

Presentation (CLIP) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[17] ETSI ETS 300 093-1 : "Integrated Services Digital Network (ISDN); Calling Line Identification 

Restriction (CLIR) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[18] ETSI ETS 300 097-1: "Integrated Services Digital Network (ISDN); Connected Line Identification 

Presentation (COLP) supplementary service; Digital Subscriber Signalling System No. one 
(DSSl) protocol; Part 1: Protocol specification". 

[19] ETSI ETS 300 098-1 : "Integrated Services Digital Network (ISDN); Connected Line Identification 

Restriction (COLR) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[20] ETSI ETS 300 130-1: "Integrated Services Digital Network (ISDN); Malicious Call Identification 

(MCID) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[21] ETSI ETS 300 138-1 : "Integrated Services Digital Network (ISDN); Closed User Group (CUG) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 
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[22] ETSI ETS 300 141-1 : "Integrated Services Digital Network (ISDN); Call Hold (HOLD) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[23] ETSI ETS 300 185-1: "Integrated Services Digital Network (ISDN); Conference call, add-on 

(CONE) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[24] ETSI ETS 300 188-1: "Integrated Services Digital Network (ISDN); Three-Party (3PTY) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[25] ETSI EN 300 196-1: "Integrated Services Digital Network (ISDN); Generic functional protocol for 

the support of supplementary services; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[26] Void. 

[27] ETSI EN 300 485 (VI. 2.3): "Integrated Services Digital Network (ISDN); Definition and usage of 

cause and location in Digital Subscriber Signalling System No. one (DSSl) and Signalling System 
No.7 ISDN User Part (ISUP) [ITU-T Recommendation Q.850 (1998), modified]". 

[28] ETSI TS 183 054: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Protocol specification Closed 
User Group (CUG)". 

[29] ETSI EN 300 403-1: " Integrated Services Digital Network (ISDN); Digital Subscriber SignalHng 

System No. one (DSSl) protocol; Signalling network layer for circuit-mode basic call control; 
Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993), modified]". 

[30] ITU-T Recommendation Q.951: "Digital Subscriber Signalling System No. 1 Stage 3 Description 

for Supplementary Services Using DSS 1". 

[31] ETSI TS 183 047: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN IMS Supplementary Services; Advice Of Charge 
(AOC)". 

[32] ETSI TS 183 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Common Basic Communication procedures; Protocol 
specification" . 

[33] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Interworking between the IP Multimedia (IM) Core 
Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163 version 7.7.0 
Release 7)". 

[34] ETSI EN 300 207-1 : "Integrated Services Digital Network (ISDN); Diversion supplementary 

services; Digital Subscriber Signalling System No. One (DSSl); Part 1: Protocol specification". 

[35] ETSI EN 300 369-1 : "Integrated Services Digital Network (ISDN); ExpHcit Call Transfer (ECT) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[36] ETSI TS 183 029: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services: Explicit Communication 
Transfer (ECT); Protocol specification". 

[37] ETSI EN 300 182-1 : "Integrated Services Digital Network (ISDN); Advice of Charge (AOC) 

supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 

[38] ETSI ETS 300 286-1 : "Integrated Services Digital Network (ISDN); User-to-User Signalling 

(UUS) supplementary service; Digital Subscriber Signalling System No. one (DSSl) protocol; 
Part 1 : Protocol specification" . 



ETSI 



1 1 ETSI TS 1 83 036 V2.1 .1 (2009-01 ) 

[39] ETSI EN 300 359-1 : "Integrated Services Digital Network (ISDN); Completion of Calls to Busy 

Subscriber (CCBS) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[40] ETSI EN 301 065-1 : "Integrated Services Digital Network (ISDN); Completion of Calls on No 

Reply (CCNR) supplementary service; Digital Subscriber Signalling System No. one (DSSl) 
protocol; Part 1: Protocol specification". 

[41] ETSI TS 183 042: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN Simulation Services; Completion of 
Communications to Busy Subscriber (CCBS), Completion of Communications by No Reply 
(CCNR); Protocol Specification". 

[42] ETSI TS 183 043: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Stage 3 specification". 

[43] ETSI EN 301 798 (VI. 1.1): "Services and Protocols for Advanced Networks (SPAN); Anonymous 

Call Rejection (ACR) Supplementary Service; Service description". 

[44] IETF RFC 4575 (August 2006): "A Session Initiation Protocol (SIP) Event Package for 

Conference State". 

[45] IETF RFC 4244: "An Extension to the Session Initiation Protocol (SIP) for Request History 

Information" . 

[46] ETSI TS 183 016: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Malicious Communication 
Identification (MCID); Protocol Specification". 

[47] IETF RFC 3966: "The tel URI for Telephone Numbers". 

[48] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

[49] ETSI TS 183 023: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Extensible Markup Language 
(XML) Configuration Access Protocol (XCAP) over the Ut interface for Manipulating NGN 
PSTN/ISDN Simulation Services". 

[50] IETF RFC 4916: "Connected Identity in the Session Initiation Protocol (SIP)". 

[5 1 ] IETF RFC 4040: "RTP Payload Format for a 64 kbit/s Transparent Call" . 

[52] IETF RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)". 

[53] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[54] ITU-T Recommendation Q.931: "ISDN user-network interface layer 3 specification for basic call 

control". 

[55] ITU-T Recommendation Q.939: "Typical DSS 1 service indicator codings for ISDN 

telecommunications services". 

[56] ITU-T Recommendation T.38: "Procedures for real-time Group 3 facsimile communication over 

IP networks". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] draft-johnston- sipping-cc-uui-02.txt. 

[i.2] ITU-T Recommendation Q.763: "Signalling System No. 7 - ISDN User Part formats and codes". 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

en bloc receiving: procedure, used in call establishment of an incoming call, to enable the network to send called party 
number digits to the user in a single message 

NOTE: See EN 300 403-1 [29]. 

en bloc sending: procedure, used in call establishment of an outgoing call, to enable the user to send called party 
number digits to the network in a single message 

NOTE: See EN 300 403-1 [29]. 

Incoming AGCFA^GW: physical entity, which can be combined with a SIP UNI or NNI, terminates incoming calls 
using SIP protocol and originates outgoing calls using the DSSl protocol 

Outgoing AGCFA^GW: physical entity, which can be combined with an ISDN access device, terminates incoming 
calls using DSSl and originates outgoing calls using the SIP protocol 

overlap receiving: procedure, used in call establishment of an incoming call, to enable the network to send called party 
number digits to the user in successive messages, as and when they are made available from the remote network 

NOTE: See EN 300 403-1 [29]. 

overlap sending: procedure, used in call establishment of an outgoing call, to enable the user to send called party 
number digits to the network in successive messages, as and when they are made available by the user 

NOTE: See EN 300 403-1 [29]. 

user: DSSl protocol entity at the user side of the user-network interface 

NOTE: See EN 300 403-1 [29]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACK ACKnowledgement 

AGCF Access Gateway Control Function 

BC Bearer Capaability information element 

BRI Basic Rate Access 

CLIP Calling line Identification Presentation 

CLIR Calling line Identification Restriction 

COLP Connected Line Identification Presentation 

COLR Connected Line Identification Restriction 

CUG Closed User Group 

HOLD communication HOLD 

IFC Initial Filter Criteria 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

IWF InterWorking Function 

MCID Malicious Communication IDentification 

MRFC Multimedia Resource Function Controller 

NGN Next Generation Network 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 
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PES PSTN/ISDN Emulation Subsystem 

PRI Primary Rate Access 

PSTN Public Switched Telephone Network 

S-CSCF Server-Call Session Control Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

SUB SUBaddressing 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UA User Agent 

UE User Equipment 

URI Universal Resource Identifier 

UUS User User Service 

VGW Voice over IP GateWay 

XCAP PSTN/ISDN simulation services Extensible Markup Language (XML) Configuration Access 

Protocol 

XML extensible Markup Language 



General 



The present document describes guiding principles for implementing commonly deployed ISDN basic call and 
supplementary services using the IMS and IMS-based PES architecture. 

• ISDN terminals are connected to VGW or access gateways AGCF using BRI or PRI interfaces. The protocol 
running on the interfaces between these gateways and the PES is the session initiation 
protocol (SIP). 

The actual service logic resides in the Application Server and is outside the scope of standardization. This clause 
focuses on the interactions between the IWF. 

Full support of supplementary services may be realized by exchanging service information between peer SIP signalling 
entities via SIP signalling. The DSSl information necessary to support each individual service is specified by the 
corresponding ETSI or ITU-T supplementary service specification; see table 4-1. For the management of several 
supplementary services (e.g. activation or deactivation of a service), two possibilities exist. The usage of the Ut 
interface allows the transport of the content of the DSSl Facility in PSTN XML instances as specified in the relevant 
simulation service to the XCAP server to manipulate the service. In addition, the usage of an empty INVITE to carry 
service code sequences is also applicable to manipulate the supplementary service. The applicability is a network 
provider option. The management of supplementary services in PES is out of scope of the present document. 

In case of the interworking for IMS simulation the mapping of PSTN XML Attachment parameters Progresslndicator 
HighLayerCapability, LowLayerCapability, BearerCapability, Display; CUGcallOperation and additional P-Early 
media header are a network provider option, in the IMS based PES they are mandatory. 
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Table 4-1 : Supplementary Service References 



Supplementary Service 


ETSI Reference 


Calling Line Identification Presentation (CLIP) 


f16l 


Calling Line Identification Restriction (CLIR) 


f17l 


Connected Line Identification Presentation (COLP) 


[181 


Connected Line Identification Restriction (COLR) 


[191 


Terminal Portability (TP) 


[121 


User-to-User Signalling (UUS) 


[381 


Closed User Group (CUG) 


[21] 


Subaddressing (SUB) 


[141 


Malicious Call Identification (MCID) 


[201 


Conference Call (CONF) 


[231 


Explicit Call Transfer (ECT) 


[351 


Call Fonwarding Busy (CFB) 


[34] 


Call Fonwarding No Reply (CFNR) 


[341 


Call Fonwarding Unconditional (CFU) 


[341 


Call Deflection (CD) 


[341 


Call Hold (HOLD) 


[221 


Call Waiting (CW) 


[13] 


Completion of Calls to Busy Subscriber (CCBS) 


[391 


Three-Party (3PTY) 


[241 


Completion of Calls on No Reply (CCNR) 


[401 


Anonymous Communication Rejection (ACR) 


[43] 



Interworking for IMS simulation / emulation services 



5.1 



Basic Call 



5.1 .1 Actions at the Outgoing AGCF/VGW 



5.1.1.1 



Sending of the Initial INVITE 



After initiating the normal incoming call establishment procedures, determining the end of address signalling and 
selecting to route the call to the IMS domain, the originating VGW/AGCF shall send the initial INVITE. As a network 
option, the originating VGW/AGCF may send INVITE requests without determining the end of address signalling . 

The end of address signalling shall be determined by the earlier of the following criteria: 

a) by receipt of a "#" character as a sending complete indication or Sending complete information element; 

b) optional by receipt of the maximum number of digits used in the national numbering plan; or 

c) optional by analysis of the called party number to indicate that a sufficient number of digits has been received 
to route the call to the called party. 

Table 5.1 .1.1-1: Mapping of sending complete info element 



SETUP/INFO ^ 


INVITE/XXX ^ 


Information element 


PSTN XML attachment 


sending complete 


sendingCompletelndication 



NOTE: The sendingCompletelndication is an extension of the existing PSTN XML body as specified in 
ES 283 003 [3] andTS 129 163 [33]. 
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5.1.1.1.1 



En-bloc sending according to EN 300 403-1 , clause 5.1 .1 



If en-bloc sending is used, the SETUP message contains the complete called number information. The called party 
number information is included in the Called party number information element possibly completed by the Called party 
subaddress information element. 

The network shall send a CALL PROCEEDING message to the user. This acknowledges the SETUP message and 
indicates that the call is being processed and that no further address information is expected. 

The AGCFA^GW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in Called party number information element. Among other purposes, this digit map can be used to 
identify the required number of digits to be entered for a particular digit sequence for a particular service. The 
procedures for digit maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. 

Even in the absence of a digit map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall 
contain a configurable parameter indicating the minimum number of digits expected in the sequence of Called party 
number information elements before a Request-URI is constructed and an INVITE request sent. The minimum number 
could be zero. 

If this option does not apply, the VGW has to assume overlap sending. 

If en-bloc sending is used, the SETUP message may contain the sending complete indication (IE the Sending complete 
information element) (see EN 300 403-1 [29]). 

It is mandatory for the network to recognize the Sending complete information element. 



5.1.1.1.2 



Bearer capability mapping 



The "information transfer capability" code point of the bearer capability information element in the SETUP message 
shall be mapped to the SDP in SIP according to table 5.1.1.1.2-1. 

Table 5.1 .1 .1 .2-1 : Coding of the BC received 



SETUP ^ 


INVITE^ 


Bearer capability information element 


Coding of SDP media description lines from BC/HLC to SIP 


Information transfer capability 




Speech 


see table 5.1.1.1.4-2 


3,1 kHz audio 


see table 5.1.1.1.4-2 


Unrestricted digital inf. W/tone/ann 


see table 5.1.1.1.4-2 


unrestricted digital information 


see table 5.1.1.1.4-2 



In addition, the whole bearer capability information element, as received in the SETUP message, shall be mapped to the 
PSTN XML bearer capability body in SIP, according to table 5.1.1.1.2-2. 

If two EC's are received then: 

• the BC 2 shall be mapped to the first SDP entry of the SIP INIVITE; and 

• the BC 1 shall be mapped to the second SDP entry of the SIP INVITE; and 

• the AGCFA^GW shall store the BC values. 

This is needed for the Fall back mechanism as described within clause 5.1.1.2.2. 
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Table 5.1.1.1.2-2: Mapping of Bearer capability to PSTN XML BearerCapability 



SETUPS 


INVITE^ 


Content 


PSTN XML attachment BearerCapability 


One BC received: 
BC 


BearerCapability mapped from the BC 
Information element (see note 2) 


Two BC received (see note 1): 
BC 1 {speech or 3, 1 kHz audio) 
BC 2 (unrestricted digital information witli 

tones and announcements) 


BearerCapability 1 mapped from the BC 1 
Information element (see note 2) 
BearerCapability 2 mapped from the BC 2 
Information element (see note 2) 


NOTE 1 : BC 1 is the bearer capability information element received in first position in the SETUP 
message, BC 2 in the second position. Bearer capability information elements shall be 
received in ascending order of priority as described in 5.11.1.1/Q.931 [54]. 

NOTE 2: Octet 1 (information element identifier) and 2 (length) of the bearer capability 
information element are not included. 



5.1 .1 .1 .3 Mapping of Progress indicator/High Layer Compatibility/Low Layer Compatibility 

IE 

A progress indicator IE, high layer compatibility IE, or low layer compatibility IE, if received in a SETUP message, 
shall be mapped to the PSTN XML attachment in SIP, according to table 5.LL1.3-L 

Table 5.1.1.1.3-1: Mapping of the Progress indicator/High Layer 
Compatibility/Low Layer Compatibility IE 



SETUPS 


INVITE^ 


Content 


PSTN XML Attachment 


Progress indicator 


Progresslndicator 


High layer compatibility 


HighLayerCapability 


Low layer compatibility 


LowLayerCapability 



Table 5.1 .1 .1 .3-2: Mapping of the High Layer Compatibility 



SETUPS 


INVITE ^ 


Content 


PSTN XML 


One HLC received: 
HLC 


HighLayerCapability HLC 


Two HLC received (see note 1): 
HLC1 
HLC 2 


HighLayerCapability (content of HLC 1) (see note 2) 
HighLayerCapability (content of HLC 2) (see note 2) 


NOTE 1 : HLC 1 Is the high layer compatibility information element received in first position in the 
SETUP message, HLC 2 in second position. High layer compatibility information 
elements shall be received in ascending order of priority as described in 
5.12.1. 1/Q.931 [54]. 

NOTE 2 Octets 1 (information element identifier) and 2 (length) of the high layer compatibility 
information element are not included. 
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Table 5.1.1.1.3-3: Coding of the progress indicator information element 



SETUPS 


INVITE^ 


Progress indicator information 
element 


XML attachment 


No. Value of PI (see note 1) 


PSTN XML with Progresslndicator No (Value of PI) 
PSTN XML with Progresslndicator. No. 6 (see note 2) 




PSTN XML with Progresslndicator. No. 6 (see note 2) 


NOTE 1 : Except value 

No. 2 - Indicates that the destination user is not ISDN; 

No. 8, "in-band information or an appropriate pattern is now available". 
NOTE 2: The ISDN access indicator - "originating access ISDN" is transported in the IMS 

as PSTN XML Progresslndicator No. 6 see annex E. 



The calling and called party subaddress information shall be mapped to SIP as described in clause 5.2.8. 



5.1.1.1.4 



Request URI/To header field 



Table 5.1.1.1.4-1: Mapping DSS1 Called Party Number to 
SIP Request-URI and To header field 



SETUP 


INVITE 


Called Party Number 


Request-URI and To header field 


Type of number 




Unknown 




Dialled strings 

E. 164 Number format 
LN (local number) 


Option a) 

sip: dialled digits@homehostportion (see note) 

Option b) 

sip: dialled digits; phone-context=<xxxxxx >@homehostportion; user=xxxx 

(see note 1 ) 

Option c) 

sip: dialled digits @homehostportion; user=xxxx (see note) 


E. 164 Number format 
Prefix+NDC+SN 
(national number) 


E. 164 Number format 
Prefix + CC+NDC+SN 
(international number) 


Subcriber number 


Option a) 
sip:subscribernumber@homehostportion (see note) 

Option b) 

sip: subscribernumber; phone-context=<xxxxxx>@homehostportion; 

user=xxxx (see note) 

option c) 

tel: subscribernumber;phone-context= <xxxxxx> (see note) 
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SETUP 


INVITE 


Called Party Number 


Request-URI and To header field 


Type of number 




Network specific number 


Option a) 

sip: network-specific-number@homehostportion (see note) 

Option b) 

sip: network-specific-number;phone- 

context=<xxxxxx>@homehostportion;user=xxxx (see note) 


Abbreviated number 


Option a): 

sip: dialed digits@homehostportion (see note) 

Option b): 

sip: dialed digits; phone-context=<xxxxxxx>@homehostportion; user=xxxx 

(see note) 


National number 


Option a) 

sip: national number@homehostportion (see note) 

Option b) 

sip: national number; phone-context=< xxxxxx>@homehostportion; user=xxxx 

(see note) 

Option c) 

tel: national number;phone-context=<xxxxxx> (see note) 


International number 


Option a) 

sip: "+" dialled digits@homehostportion; user= phone (see note) 

Option b) 

tel: "+" dialled digits (see note) 


NOTE: The combination of digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 
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Table 5.1.1.1.4-2: Coding of SDP media description lines from BC/HLC to SIP 



BC IE (normative) 


HLC IE in 
(Optional) 


m= line 


b= line 


a= line 


Information 
Transport Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


<media> 


<transport> 


<fmt-list> 


<modifier 

>: 
<bandwid 
th-value> 


rtpmap:<dynamic-PT> 

<encoding name>/<clock 

rate>/encoding parameters> 


"Speech" 


"G.71 1 M-law" 


Ignore 


Audio 


RTP/AVP 


(and possibly 
8) (see note 1 ) 


AS:64 


rtpmap:0 PCMU/8000 
(and possibly rtpmap:8 
PCMA/8000) 
(see note 1 ) 


"Speech" 


"G.71 1 M-law" 


Ignore 


Audio 


RTP/AVP 


Dynamic PT 

(and possibly a 

second Dynamic 

PT) 

(see note 1 ) 


AS:64 


rtpmap:<dynamic-PT> 

PCMU/8000 

(and possibly rtpmap:<dynamic- 

PT> PCMA/8000) (see note 1) 


"Speech" 


"G.711 A-law" 


Ignore 


Audio 


RTP/AVP 


8 


AS:64 


rtpmap:8 PCMA/8000 


"Speech" 


"G.711 A-law" 


Ignore 


Audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
PCMA/8000 


"3,1 kHz audio" 


"G.711 M-law" 


Ignore 


audio 


RTP/AVP 


(and possibly 

8) 

(see note 1 ) 


AS:64 


rtpmap:0 PCMU/8000 
(and possibly rtpmap:8 
PCMA/8000) (see note 1) 


"3,1 kHz audio" 


"G.71 1 A-law" 


Ignore 


audio 


RTP/AVP 


8 


AS:64 


rtpmap:8 PCMA/8000 


"3,1 kHz audio" 


"G.71 1 A-law" 


"Facsimile Group 
2/3" 


image 


UdptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 


"3,1 kHz audio" 


"G.71 1 A-law" 


"Facsimile Group 
2/3" 


image 


TcptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 
isup_usi mapped from BC IE (see 
note 4) 


"3,1 kHz audio" 


"G.71 1 M-law" 


"Facsimile Group 
2/3" 


image 


UdptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 
isup_usi mapped from BC IE (see 
note 4) 


"3,1 kHz audio" 


"G.71 1 M-law" 


"Facsimile Group 
2/3" 


image 


TcptI 


t38 [56] 


AS:64 


Based on ITU-T Rec. T.38 [56] 


"Unrestricted digital 
inf. W/tone/ann." 
(see notes 4 and 5) 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


"Unrestricted digital 
information" 


N/A 


Ignore 


audio 


RTP/AVP 


Dynamic PT 


AS:64 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


NOTE 1 Both PCMA and PCMU could be required. 

NOTE 2 CLEARMODE is specified in RFC 4040 [51 ]. 

NOTE 3: The mapping of the "Information Transport Capability" to the proper codec is explained in annex C 

NOTE 4: In case of receiving two BC elements and each shall be mapped to an m line. The Fallback possibility is described within clause 5.1 .1 .2.2 

NOTE 5 After the CLEARMODE codec, an additional speech codec G.71 1 should be offered in the same m-line. 
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5.1.1.2 



Receipt of a Provisional Response 18x 



The SDP answer is described in annex C. 



5.1.1.2.1 



180 Ringing response 



Depending on the following three cases, the AGCF/VGW shall send an ALERTING message across the 
user-network interface to the calling user, as described in table 5.1.1.2.1-1. 

• the reception of the first 180 Ringing response without a P-Early-Media header (authorizing early media); or 

AGOWGW 



ATFRTING 


180 Ringing 






Ring tone 




^ .....«...•..__.••• 





Figure 5.1 .1 .2.1 -1 : Sending of ALERTING (Receipt of first 1 80 Ringing 
without authorization of early media) 

NOTE: The ringing tone is sent only for voice services. 

• the reception of the first 180 Ringing with a P-Early-Media header (authorizing early media); or 

AGCFA^GW 



ALERTING with PI#8 


180 Ringing 
P-Early-Media 






^. __.««. ._.«««..__. 


Ring tone 


■^^ — — ■— ^ ^ ^ ^ — — ■— ^ ^ ^ ^ — — ■— 





Figure 5.1.1.2.1-2: Sending of ALERTING (Receipt of first 180 Ringing 
that includes authorization of early media) 

NOTE: Based on local knowledge that the call is transited to a PSTN network, the AGCFA^GW can make a 

decision not to generate the awaiting answer indication when receiving the 180 Ringing message without 
a P-Early-Media header. 

• once all the following sub-conditions have been met: 

1) the reception of the first 183 Session Progress that includes a P-Early-Media header authorizing early 
media; 

2) the SDP offer/answer procedures are completed; and 

3) SDP preconditions are not used, or applicable SDP preconditions have been met. 
The support of the reception of the P-Early-Media header is mandatory for the AGCF/VGW. 
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If the AGCF/VGW receives a 18x response with a P-Early-media header that changes the authorization of early media: 

if the header authorizes early media and if the AGCF/VGW is sending the awaiting answer indication, the 
AGCF/VGW shall terminate the sending of the awaiting answer indication; and 

if the header removes authorization of early media and if the AGCF/VGW has received the 180 Ringing 
response, the AGCF/VGW shall initiate the sending of the awaiting answer indication. 

In the event of the P-Early-Media header not being present in the 18x message and a media flow being received, such a 
media flow would ideally not be authorized. However, under these circumstances, a VGW may, as a network option, 
forward the received media flow and send an ALERTING, CALL PROCEEDING or PROGRESS message with a 
Progress Indicator set to 8 (In-band information or appropriate pattern now available). 

NOTE: This behaviour enables managing the case when the remote entity generating early media does not 
support the P-Early-Media header. 

Table 5.1.1.2.1-1: Message sent to the DSS 1 upon receipt of 180 



^Message sent to the DSS 1 
ALERTING 


<r- 180 Ringing 


Progress indicator 
information element 




No. 1 (see note 1) 

(Call is not end-to-end ISDN: further progress information 

may be available in-band) 


No PSTN XML Progresslndicator 


No. 8 (see note 1) 

[In-band information or appropriate pattern 

now available) 


P-Earl-Media header 


No. Value of PI (see note 2) 


PSTN XML with Progress indicator No (Value of PI) and 
PSTN XML Progresslndicator No.7 (see note 2) 




PSTN XML with Progress indicator No 7 (see note 2) 


NOTE 1 : The progress indicator is only sent if the BC received in the SETUP message is coded "speech", "3,1 kHz 

audio" or "unrestricted digital information with tones and announcements". 
NOTE 2: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No.7 and is not sent to the access see annex E. 



5.1.1.2.1.1 



Progress indicator 



If the Progress indicator information elements are present in the PSTN XML: attachment of the SIP Provisional 
Response, they shall be transferred in the DSSl message sent to the calling user. 

In addition, progress indicator information elements are created by the originating AGCF/VGW according to 
table 5.1.1.2.1-1. 

In case of fallback to an alternative bearer capability or high layer compatibility, according to EN 300 403-1 [29], 
clauses 5.11 and 5.12, a progress indicator No. 5 (interworking has occurred and has resulted in a telecommunication 
service change) shall be sent by the ACGFA^GW, as described in tables 5.1.1.2.1.2-1 and 5.1.1.2.1.3-1. 

Every message sent to the DSSl user (ALERTING, CALL PROCEEDING or PROGRESS) may contain two progress 
indicator information elements. When more than two progress indicator information elements are to be sent, the 
subsequent progress indicator information elements are sent in a PROGRESS message. 



5.1.1.2.1.2 



High layer compatibility 



If a high layer compatibility information element is present in the PSTN XML attachment of the SIP Provisional 
Response, the mapping to the HLC IE is described in table 5.1.1.2.1.2-1. 
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Table 5.1.1.2.1.2-1 Sending of HLC fallback information 



^Message sent to DSS 1 


^180 


Content 


PSTN XML attachment 


HLC 


HighLayerCompatibility 


NOTE: The HighLayerCompatibility information in the PSTN XIVIL attachment of the SIP body shall be mapped, if 
present, to the HLC IE (EN 300 403-1 [29], clause 4.5.17, table 4-23/Q.931 [54]). 



5.1 .1 .2.1 .3 Handling of fallback information 

a) Bearer capability selection procedure 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.2.1.3-1. 

Table 5.1 .1 .2.1 .3-1 : Sending of BC fallback information 



^Message sent to DSS 1 
CONNECT 


^180 




PSTN XML attachment 


Bearer Capability derived from PSTN XML 
BearerCapability element see table 5.1 .2.1-2 


BearerCapability {speech or 3,1 kHz audio) 
(see note 2) 


Progress Indicator. No. 5 (see note 1) 




NOTE 1 : The AGCF/VGW may send the Progress Indicator No. 5 also in a PROGRESS message to the user. 
NOTE 2: The received BearerCapability information should contain a Speech or 3,1 kHz BC. 



If a high layer compatibility information element is present in the PSTN XML attachment of the 1 80 Ringing, and if no 
progress indicator No. 1 (call is not end-to-end ISDN) or No. 2 (destination address is non-ISDN) has to be sent, 
table 5.1.1.2.1.3-1 is appHcable. 

b) High layer compatibility selection procedure 

According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.2.1.3-2, 

Table 5.1.1.2.1.3-2: Sending of HLC fallback information 



^Message sent to DSS 1 


^180 


ALERTING 


PSTN XML attachment 


HLC (as received in the PSTN XML attachment) 
Progress indicator No. 5 


HighLayerCapability 


NOTE 1 : If procedures of BC fallback and HLC fallback both require the sending of the progress indicator No. 5, only 

one progress indicator No. 5 is sent. 
NOTE 2: The AGCF/VGW may send the Progress Indicator No.5 also in a PROGRESS message to the user. 



c) SDP selection procedure: 

When a SDP answer was received indicating no support of the 7 kHz call setup (CLEARMODE codec not the first 
codec in the m line), the fallback shall apply as described in table 5.1.1.2.1.3-3. 

Table 5.1.1.2.1.3-3: Sending of fallback information no support in the SDP 



^Message sent to DSS 1 


^180 


ALERTING 


SDP 


B {speech or 3, 1 kHz audio) 
Progress Indicator No. 5 (see note) 


CLEARMODE not the first codec on the codec list 


NOTE: The AGCF/VGW may send the Progress Indicator No.5 also in a PROGRESS message to the user. 
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5.1.1.2.2 Receipt of the 183 (Session Progress) response 

Once all the following sub-conditions have been met: 

• if the AGCFA^GW has received the first 183 Session Progress that includes a P-Early-Media header 
(indicating authorization of early media); and 

• SDP preconditions are not used or applicable SDP preconditions have been met. 

The AGCF/VGW shall send a CALL PROCEEDING or PROGRESS message according to table 5.1.L2.1.3-2 to the 
calling user, as described in table 5.LL2.L3-2. 

O-AGCFA^GW 



CALL PROC/PROGRESS 

in-band inforrriaition availablp> 


183 Progress 
P-Early-Media 






4 


appropriate announcement 



Figure 5.1.1.2.2-1: Sending of Call Proceeding (Receipt of first 183 that includes 

authorization of early media) 

In the event of the P-Early-Media header not being present in the 18x message and a media flow being received, such a 
media flow would ideally not be authorized. However, under these circumstances, a VGW may, as a network option, 
forward the received media flow and send an ALERTING, CALL PROCEEDING or PROGRESS message with a 
Progress Indicator set to 8 (In-band information or appropriate pattern now available). 

NOTE: This behaviour enables managing the case when the remote entity generating early media does not 
support the P-Early-Media header. 
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5.1 .1 .2.2.1 Progress indicator 

Table 5.1.1.2.2.1-1 : Message sent to the DSS 1 interface upon receipt of 183 

(Session Progress) response 



^IVIessage sent to the DSS 1 


^ 183 Session Progress 


CALL PROCEEDING when not been sent 
before (see note 1 ) 


Progress Indicator IE: 
Progress description No. 8 (see note 3) 
(In-band information or appropriate 
pattern now available) 


P-Earl-Media header 


Progress Indicator IE: 

Progress description No. Value of PI 

(see note 5) 


PSTN XML with Progress 
indicator (Value of PI) 
Progresslndicator No. 7 
(see note 5) 




PSTN XML 

Progresslndicator No. 7 
(see note 5) 


PROGRESS if a progress indicator 
information element is contained in 183 
(see note 2) 


Progress Indicator IE: 
Progress description No. 8 (see note 3) 
(In-band information or appropriate 
pattern now available) 


P-Earl-Media header 


Progress Indicator IE: 

Progress description No. Value of PI 

(see note 5) 


PSTN XML with Progress 
indicator (Value of PI) and 
PSTN XML 

Progresslndicator No. 7 
(see note 5) 




PSTN XML 

Progresslndicator No. 7 
(see note 5) 


NOTE 1 : The receipt from the network of an 183 is interpreted by the network as a sending complete indication, in 

the case where the network couldn't determine it before. 
NOTE 2: The sending of a progress indicator information element is described above. 
NOTE 3: The progress indicator is only sent if the BC received in the SETUP message is coded speech, 3, 1 kHz 

audio. 
NOTE 4: If a PSTN XML attachment HLC is received, it shall be mapped to the HLC IE. 
NOTE 5: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No. 7 and is not sent to the access. 



If more than two progress indicator information elements are to be sent, the subsequent progress indicator information 
elements shall be sent in a PROGRESS message. 



5.1.1.2.2.2 



High layer compatibility 



If a high layer compatibility information element is present in the PSTN XML attachment of the 183 Session Progress, 
see handling of fallback information at the end of this clause. 

5.1 .1 .2.2.3 Handling of fallback information 

a) Bearer capability selection procedure 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.2.2.3-1. 

Table 5.1.1.2.2.3-1: Sending of BC fallback information 



^Message sent to DSS 1 


^183 Session Progress 


CALL PROCEEDING or PROGRESS 


PSTN XML attachment 


Bearer Capability derived from PSTN XML 
BearerCapability element see table 5.1 .2.1-2 


BearerCapability (speech or 3,1 kHz audio) 
(see note 2) 


Progress Indicator. No. 5 (see note 1) 




NOTE 1 : The AGCF/VGW may send the Progress Indicator No. 5 also in a PROGRESS message to the user. 
NOTE 2: The received BearerCapability information should contain a Speech or 3,1 kHz BC. 
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If a high layer compatibility information element is present in the PSTN XML attachment of the 183 Session Progress, 
and if no progress indicator No. 1 (call is not end-to-end ISDN) or No. 2 (destination address is non-ISDN) has to be 
sent, table 5. 1.1. 2. 1.3-1 is applicable. 

b) High layer compatibility selection procedure 

According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.2.1.3-2. 

Table 5.1.1.2.2.3-2: Sending of HLC fallback information 



^Message sent to DSS 1 


^183 Session Progress 


^ CALL PROCEEDING or PROGRESS 


PSTN XML attachment 


HLC (as received in the PSTN XML attachment) 
Progress indicator No. 5 


HighLayerCapability 
Progress indicator No. 5 


NOTE 1 : If procedures of BC fallback and HLC fallback both require the sending of the progress indicator No. 5, only 

one progress indicator No. 5 is sent. 
NOTE 2: The AGCF/VGW may send the Progress Indicator No. 5 also in a PROGRESS message to the user. 



c) SDP selection procedure: 

When a SDP answer was received indicating no support of the 7 kHz call setup (no CLEARMODE codec in the 
m line), the fallback shall apply as described in table 5.1.1.2.1.3-3. 

Table 5.1.1.2.2.3-3: Sending of fallback information no support in the SDP 



^Message sent to DSS 1 


^ 183 Session Progress 


^ CALL PROCEEDING or PROGRESS 


SDP 


B C (speech or 3,1 kHz audio) 
Progress Indicator No. 5 (see note) 


CLEARMODE not the first codec on the codec list 


NOTE: The AGCF/VGW may send the Progress Indicator No.5 also in a PROGRESS message to the user. 



5.1.1.3 



Receipt of the 200 OK INVITE 



Upon receipt of a 200 OK INVITE and the 200 OK INVITE does not contain the from-change tag in the Supported 
header, the AGCFA^GW shall send a CONNECT message across the user-network interface to the calling user. If the 
from-change tag in the Supported header is contained in the 200 OK INVITE, the applicable procedures are described 
in clause 5.2.2.2. 

The SDP answer is described in annex C. 

The CONNECT message is coded as follows. 

Table 5.1.1.3-1 : Sending criteria of the progress indicator information elements 

created by the VGW/AGCF 



^ CONNECT 


^ 200 OK 


Progress indicator 
information element 




Progress description No. 1 (see note) 

{Call is not end-to-end ISDN: further progress information 

may be available in-band) 


No PSTN XML Progresslndicator 


Progress description No. Value of PI 


PSTN XML with Progress indicator No (Value of PI) and 
PSTN XML Progresslndicator No. 7 (see note) 




PSTN XML Progresslndicator No. 7 (see note) 


NOTE: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 7 and is not sent to the access see annex E. 



NOTE: The PES AS shall assure that the correct PI and their combination is provided to the AGCFA^GW. 
The CONNECT message sent to the access may contain two progress indicator information elements. 
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When more than two progress indicator information elements are to be sent, the subsequent progress indicator 
information elements shall be sent in a PROGRESS message. 

High layer compatibility 

If a high layer compatibility information element is present in the PSTN XML attachment of the 200 OK INVITE, see 
handling of fallback information at the end of this clause. 

Low layer compatibility 

The low layer compatibility possibly present in the PSTN XML attachment of the 200 OK INVITE is passed on 
unchanged. 

History-Info header 

See clause 5.2. 

User-user 

See clause 5.2. 

P-Asserted-Identity 

See clause 5.2. 

Connected subaddress 

See clause 5.2. 

Handling of fallback information 

According to EN 300 403-1 [29], clause 5.11, the mapping shall be done as described in table 5.1.1.3-2. 

Table 5.1.1.3-2: Sending of BC fallback information 



^CONNECT (see note 1) 


^200 OK INVITE 




PSTN XML attachment 


SDP m line 


BC derived from received BearerCapability 
(Unrestricted digital information with tones 
and announcements) 


BearerCapability (unrestricted digital 
information with tones and 
announcements) (see note 2) 


The first stated codec has to be 
consistent with the PSTN XML 
BearerCapability 


BC derived from received BearerCapability 
(speech or 3,1 kHz audio) 


BearerCapability (speech or 3,1 kHz 
audio) (see note 2) 


The first stated codec has to be 
consistent with the PSTN XML 
BearerCapability 




No PSTN XML attachment 


The SDP answer has 
precedence (see note 3) 


NOTE 1 : If fallback allowed was indicated in the SETUP message, and fallback occurs at the destination, or fallback 
does not occur, the AGCF/VGW shall include in the CONNECT message the BC IE of the resultant bearer 
service. 

NOTE 2: If the SDP answer is not consistent with PSTN XML BearerCapability element, the call is released by the 
AGCF/VGW. 

NOTE 3: The SDP answer must indicate G.71 1 not CLEARMODE - if not then the AGCF/VGW releases the call. 



According to EN 300 403-1 [29], clause 5.12, the mapping shall be done as described in table 5.1.1.3-3. 

Table 5.1.1.3-3: Sending of HLC fallback information 



^CONNECT 


^200 OK INVITE 


Content 


PSTN XML attachment 


HLC 


HighLayerCapability 


Progress indicator No. 5 


Progresslndicator No. 5 


NOTE 1 : If procedures of BC fallback and HLC fallback both require the sending of the progress indicator No. 5, only 

one progress indicator No. 5 is sent. 
NOTE 2: The AGCF/VGW may also send the Progress Indicator No. 5 in a PROGRESS message to the user. 
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5.1 .1 .4 Receipt of (BYE or Final Response 

Table 5.1.1.4-1: Receipt (BYE or Final Response) 



^DISCONNECT 


^BYE/3xx/4xx/5xx/6xx 


Cause information element 


Reason header 


Cause value No. x (see notes 1 and 2) 


cause value No. x 


Progress indicator No. 8 (see note 3) 

(In-band information or appropriate pattern 

now available) 




NOTE 1 : If the cause value received in the Release message (BYE or Final Response) is unknown in DBS 1 , the 

unspecified cause value of the class is sent. 
NOTE 2: Some supplementary services, such as CUG or UUS supplementary services, require the mapping of some 

causes values; see clause 5.2. 
NOTE 3: The progress indicator is only sent if the BC received in the SETUP message is coded speech, 3, 1 kHz audio. 
NOTE 4: The location is coded '1010' network beyond interworking point. 
NOTE 5: The Progress Indicator may also be sent in a PROGRESS message. 



The handling of the other parameters is described in clause 5.2. 

The receipt of the release message (BYE or Final Response) during the user suspend/resume procedure is described in 
clause 5.2. 

NOTE: For providing tones/announcements in the disconnect indication state (EN 300 403-1 [29]), three 
possibilities are applicable: 

1) Provision of tones/announcements by the AGCF autonomously. 

2) Provision of tones/announcements under the control of the AS, for which the impact on the 
AGCF/VGW is the receipt of either a relNVITE or REFER. 

3) The AGCFA^GW has a pre-configured URI of the MRFC and establishes a session for providing 
the tones/announcements. The session to the MRFC is terminated with a BYE when a RELEASE 
message is sent or received from/to the DSSl user. 

5.1 .1 .5 Sending of (BYE or CANCEL) 

Table 5.1 .1 .5-1 : Call clearing from the user 



DISCONNECT, 

RELEASE 

RELEASE COMPLETE^ 


BYE/CANCEL^ 


Cause information element 


Reason header 


Cause value No. x 


cause value No. x 
(see notes 1 and 2) 


NOTE 1 : If the cause value received in the DSS 1 message is unknown in ISUP, the unspecified cause value of the 

class is sent. 
NOTE 2: Some supplementary services, such as CUG or UUS supplementary services, require the mapping of some 

cause values; see clause 5.2. 



5.1.1.6 



Use of Overlap Signalling (Optional) 



If Overlap SignalHng is supported between the AGCFA^GW and the originating PES AppHcation Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annexes G 
and H is dependent on national or network operator option. 
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5.1 .2 Actions at the Incoming AGCF/VGW 
5.1 .2.1 Sending of the SETUP message 

On reception of a SIP INVITE, the AGCFA^GW shall send an SETUP message. 

An AGCF/VGW shall support both incoming INVITE requests containing SIP preconditions and lOOrel extensions in 
the SIP Supported or Require headers, and INVITE requests not containing these extensions. 

If the SDP in the received INVITE request contains preconditions not met, the AGCFA^GW shall delay sending the 
SETUP until the SIP preconditions are met. 

The AGCFA^GW shall reject an INVITE request for a session only containing unsupported media types by sending a 
status code 488 (Unsupported media type). If several media streams are contained in a single INVITE request, the 
AGCF/VGW shall select one of the supported media streams, reserve the codec(s) for that media stream, and reject the 
other media streams and unselected codecs in the SDP answer, as detailed in RFC 3264 [52]. If supported audio media 
stream(s) and supported non-audio media stream(s) are contained in a single INVITE request, an audio stream should 
be selected. 

The AGCF/VGW shall include a To tag in the first backward non-100 provisional response, in order to establish an 
early dialog as described in RFC 3261 [53]. 

The information elements carried in the PSTN XML attachment of the INVITE are taken into account whatever the 
order of receipt, except when two bearer capability and/or two high layer compatibility information elements are 
received: the order of these two information elements shall be treated according to EN 300 403-1 [29], see 
table 5.1.2.1-1. 

Only the information elements involved in the interworking are described hereafter. 

The information elements used for the supplementary services are described in clause 5.2. 

For the case a PSTN XML SendingCompletelndicator is received in an INVITE, a Sending Complete information 
element is contained in the SETUP and INFO, timer T304 is not started. 

Bearer capability 

NOTE: The message side and direction has been changed to be in-line with the usual mapping as in 
EN 300 899-1 [2] ISUP-DSSl. 

Table 5.1.2.1-1 : Coding of the Bearer Capability information element (BC) 



INVITE^ 


SETUPS 


Content 


Bearer capability information element 


PSTN XML BearerCapability 


BC information is taken from PSTN XML BearerCapability 


PSTN XML BearerCapability 1 

Unrestricted digital information witli tones and 

announcements 
PSTN XML BearerCapability 2 

Speecli, or 

3, 1 kHz audio 


First BC information is derived from first PSTN XML 
BearerCapability (see note 1) 

Second BC information is derived taken from second PSTN 
XML BearerCapability (see note 1) 


No PSTN XML BearerCapability 


See table 5.1.2.1-2 


NOTE 1 : BC 1 is the bearer capability information element sent in first position in the SETUP message, BC 2 in second 
position. Bearer capability information elements shall be sent in ascending order of priority as described in 
section 5.11. 2.1/Q.931 [54]. 

NOTE 2: Basic coding of the Bearer Capability IE: 



If the INVITE does not contain SDP information but a bearer capability information in the PSTN XML body is present, 
this is an error and the call shall be rejected with the status code 606. If the INVITE message does not contain any 
bearer information (neither bearer info in SDP nor in PSTN XML body), the AGCF/VGW may postpone the sending of 
the SETUP message. The AGCF/VGW may send a SDP offer including a media description, the content of which is 
determined using local policy within a 183 (Session Progress) response message. The SETUP message shall then be 
sent when the AGCF/VGW has received sufficient information to create the BC/HLC, else the call shall be cleared with 
status code 606. 
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Table 5.1.2.1-2: Coding of from SDP: SIP to DSS1 



m= line 


b= line (see note 4) 


a= line 


BC IE (normative) (see note 1) 


HLC parameter 
(optional) 


<media> 


<transport> 


<fmt-list> 


<modifier>:<bandwi 
dth-value> 
(see note 5) 


Rtpmap:<dynamic-PT> 

<encoding name>/<clock 

rate>/encoding parameters> 


Information 
Transport 
Capability 


User Information 

Layer 1 Protocol 

Indicator 


High Layer 

Characteristics 

Identification 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 





N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 ij-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMU/8000 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMU/8000 


"3.1 kHz audio" 


"G.71 1 iJ-law" 


(see note 3) 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


8 


N/A or up to 64 kbit/s 


N/A 


"3.1 kHz audio" 


"G.711 IJ-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMA/8000 


"3.1 kHz audio" 


"G.711 A-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


N/A or up to 64 kbit/s 


rtpmap:<dynamic-PT> 
PCMA/8000 


"3.1 kHz audio" 


"G.711 IJ-law" 


(see note 3) 


Audio 


RTP/AVP 


Dynamic 
PT 


AS: 64 kbit/s 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


"Unrestricted digital 
inf. W/tone/ann." 


Mapped from the 
PSTN XML 
attachment 


Mapped from the XML 
attachment 


Audio 


RTP/AVP 


Dynamic 
PT, 


AS: 64 kbit/s 


rtpmap:<dynamic-PT> 
CLEARMODE/8000 


"Unrestricted 
digital inf. 
W/tone/ann." 
(see notes 6 and 7) 


Mapped from the 
PSTN XML 
attachment 


Mapped from the XML 
attachment 


Audio 


RTP/AVP 


Dynamic 
PT 


AS: 64 kbit/s 


Rtpmap:<dynamic-PT> 
CLEARMODE/8000 
(see note 2) 


"Unrestricted digital 
information" 


Mapped from the 
PSTN XML 
attachment 




Image 


UdptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 A-law" 


"Facsimile Group 2/3" 


Image 


TcptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 A-law" 


"Facsimile Group 2/3" 


Image 


UdptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.711 IJ-law" 


"Facsimile Group 2/3" 


Image 


TcptI 


t38 [56] 


N/A or up to 64 kbit/s 


Based on ITU-T Rec. T.38 [56] 


"3.1 kHz audio" 


"G.71 1 1J-law" 


"Facsimile Group 2/3" 


NOTE 1 : In this table the codec G.71 1 is used only as an example. Other codecs are possible. 

NOTE 2: CLEARMODE is specified in RFC 4040 [51]. 

NOTE 3: HLC is normally absent in this case. It is possible for HLC to be present with the value "Telephony", although 6.3.1/Q.939 [55] indicates that this would 

normally be accompanied by a value of "Speech" for the Information Transfer Capability element. 
NOTE 4: If the b=line indicates a bandwidth greater than 64kbit/s then the call may use compression techniques or reject the call with a 415 response indicating 

that only one media stream of 64kbit/s is supported. 
NOTE 5: <bandwidth value> for <modifier> of AS is in units of kbit/s. 

NOTE 6: The mapping of the "Information Transport Capability" to the proper codec is explained in annex C. 
NOTE 7: The value "Unrestricted digital inf. w/tones/ann" should only be used if the Clearmode codec appears together with speech codecs in the same m-line. 
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Progress indicator 



Table 5.1.2.1-3: Coding of the progress indicator information element 



INVITE^ 


SETUPS 




Progress indicator information element 


PSTN XML attachment 


Progresslndicator. No. (Value of PI) 
and PSTN XML and 
Progresslndicator No. 6 (see note 2) 


Progress indicator No. Value of PI (see note 1) 


Progresslndicator No. 6 (see note 2) 




No PSTN XML 


Progress indicator No. 1 


NOTE 1 : Except value No. 6 which is not defined in EN 300 403-1 [29]. 

NOTE 2: The ISDN access indicator - "originating access ISDN" is transported in the 

IMS as PSTN XML Progresslndicator No. 6 and is not sent to the access see 

annex E. 



Low layer compatibility 

If the low layer compatibility information element is present in the PSTN XML attachment, LowLayerCompatibility of 
the INVITE, it is converted into the LLC in the SETUP message. 

High layer compatibility 

If the high layer compatibility information element is present in the PSTN XML attachment, HighLayerCompatibility 
of the INVITE, it is converted into the HLC in the SETUP message. 

If two high layer compatibility information elements are received in the PSTN XML attachment, 

HighLayerCompatibility of the INVITE, they are converted into the HLC in the same order in the SETUP message (the 
meaning of HLC order is described in 5.12.3.2/Q.931 [54]). 

Calling party number 

See clause 5.2. 

Calling party subaddress 

See clause 5.2. 

Called party subaddress 

See clause 5.2. 
User-user 

See clause 5.2. 

Table 5.1.2.1-4: Mapping SIP Request-URI to DSS1 Called Party Number 



INVITE 


SETUP 


Request-URI 


Called Party Number 


E1 64 Address 

(format "+"CC+NDC+SN) 

(e.g. as User info in SIP URI with user= phone, or as tel URI) 


Type of number 




National number 
NDC+SN 


International number 
"+"CC+NDC+SN 


Subscriber number 
SN 
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5.1 .2.2 Sending of the 1 8x from the destination VGW/AGCF 

Table 5.1.2.2-1 : interworking of CALL PROCEEDING / PROGRESS 



<r- Message on the SIP 
183 Session Progress 


^Message sent to the DSS 1 
CALL PROCEEDING / PROGRESS 




Progress indicator information element 


PSTN XML with Progresslndicator Value of PI 

and 

PSTN XML Progresslndicator No. 7 (see note 2) 


No. Value of PI 


PSTN XML Progresslndicator No. 7 (see note 2) 




NOTE 1 : The P-Earl-Media header is only sent if the BearerCapability received in the INVITE message is 

coded speech, 3, 1 kHz audio. 
NOTE 2: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No. 7 see annex E. 



The SDP answer is described in annex C. 

If en bloc sending is used on the DSS 1 side, the SETUP message shall contain all the information required by the 
called user to process the call. 

If overlap sending is used, and if the SETUP message has already be sent and the SETUP ACKNOWLEDGE message 
received, an INFORMATION message is sent upon receipt of each Subsequent INVITE message. 

The following cases are possible trigger conditions of sending the 18x message: 

a) The destination VGW/AGCF has determined independently of access indications that the complete called 
party number has been received, a 183 Session Progress is sent. 

b) Overlap receiving is used on the DSS 1 side and a CALL PROCEEDING is received, a 183 Session Progress 
is sent. 

c) En bloc receiving is used on the DSS 1 side and a Progress indicator information element is received in a 
CALL PROCEEDING message or in a PROGRESS message, a 183 Session Progress is sent, (except with 
value No. 8, in-band information or an appropriate pattern is now available. No. 3, originating address is 
non-ISDN is received in a CALL PROCEEDING message or in a PROGRESS message, a 183 Session 
Progress is sent. 

d) The first ALERTING message is received a 1 80 Ringing is sent. 

e) It has been determined, in case of call failure, that a special in-band tone or announcement has to be returned 
to the calling party from the destination VGW/AGCF, a 183 Session Progress is sent. 

On speech or 3 J kHz calls, the awaiting answer indication (e.g. ring tone) is sent to the calling party upon receipt of the 
first ALERTING message. 

Table 5.1.2.2-2: interworking of ALERTING 



^180 Ringing 


^ ALERTING 




Progress indicator information element 


PSTN XML with Progress indicator Value of PI 

and 
PSTN XML Progresslndicator No. 7 (see note 2) 


No. Value of PI 


P-Early-Media header 
PSTN XML with Progress indicator 8 (see note 1) 




PSTN XML Progresslndicator No. 7 (see note 2) 




NOTE 1 : The P-Earl-Media header is only sent if the BearerCapability received in the INVITE message is 

coded "speech", "3,1 kHz audio". 
NOTE 2: The ISDN access indicator - "Terminating access ISDN" is transported in the IMS as PSTN XML 

Progresslndicator No. 7 see annex E. 



The SDP answer is described in annex C. 
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If the 180 Ringing has already been sent^ the following cases are possible trigger conditions of sending the 183 Session 
Progress: 

a) It has been determined, in case of call failure, that a special in-band tone or announcement has to be returned 
to the calling party from the destination VGW/AGCF. 

b) It has been determined that an in-band tone or announcement has to be returned to the calling party from the 
destination VGW/AGCF. 

Table 5.1.2.2-3: Contents of 183 Session Progress message 
if a 180 Ringing has already been sent 



<r- Message on the SIP 
183 Session Progress 



P-Early-Media header 
PSTN XML with Progress indicator 8 (see note 1) 



NOTE 1 : The P-Earl-Media header is only sent if the PSTN XIVIL BearerCapability received in the INVITE 

message is coded speech, 3, 1 kHz audio. 
NOTE 2: This ensures that the originating side receives an indication that the terminating access is ISDN. 



MANDATORY PARAMETERS 

None. 

OPTIONAL PARAMETERS 

The P-Early-Media header authorization of early media if it has been determined, that an in-band tone or announcement 
has to be returned to the calling party from the destination gateway. 

NOTE: Tones and announcements can as well provided by the MRFC. 

PSTN XML attachment HLC, LLC, Progress indicator, etc 

This extension carries the progress indicator information element possibly received from the called user (except the 
value No. 8). 

It may carry other information element as well: see clause 5.2 and tables 5.1.2.2-4 and 5.1.2.2-5. 

Handling of fallback information (only applicable at T reference point) 

When the terminating gateway has knowledge that the fallback capability was requested in the Initial INVITE, and if no 
progress indicator No. 1 or No. 2 has been received from the DSS 1 side, tables 20 and 21 are applicable. 

See clause 5.2. 

History-Info header 

See clause 5.2. 

Handling of fallback information (only applicable at T reference point) 

When the terminating gateway has knowledge that the fallback capability was requested in the Initial INVITE, and if no 
progress indicator No. 1 or No. 2 has been received from the DSS 1 side, tables 5.1.2.2-4 and 5.1.2.2-5 are applicable. 

Table 5.1.2.2-4: Handling of BC fallback information 



^18x 


^Message received from 
the access 


PSTN XML attachment 


Content 


BearerCapability derived from received DSS1 BC 
{speech or 3, 1 kHz audio) 
Progresslndicator. No. 5 


BC low 

{speech or 3,1 kHz audio) 

p.i. No. 5 



The SDP answer is described in annex C. 
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Table 5.1.2.2-5: Handling of HLC fallback information 



^18x 


^Message received from the access 


PSTN XML attachment 


Content 


HighLayerCompatibility 
Progresslndicator. No. 5 


HLC 
Progress indicator No. 5 



The SDP answer is described in annex C. 

5.1 .2.3 Sending of the 200 OK INVITE 

Upon receipt of the CONNECT message, the destination AGCFA^GW shall: 

• stop the sending of the awaiting answer indication (if any); 

• send the 200 OK INVITE to the preceding entity. 

NOTE: Tones and announcements can as well provided by the MRFC. 
The 200 OK INVITE is coded as follows: 
OPTIONAL PARAMETERS 
P-Asserted-Identity 
See clause 5.2. 

A second identity is also delivered in a changed From header in an UPDATE request, in detail described in clause 5.2.2. 
PSTN XML attachment 

Table 5.1.2.3-1 : Contents of the PSTN XML attachment 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Information elements 


Progresslndicator No (Value of PI) 

and 

Progresslndicator No 7 (see annex E) 


Progress indicator No. Value of PI 


LowLayerCompatibility 

and 

Progresslndicator No 7 (see annex E) 


Low layer compatibility 


High layer compatibility 

and 

Progresslndicator No. 7 (see annex E) 


High layer compatibility 


Bearer Capability 

and 

Progresslndicator No. 7 (see annex E) 


Bearer Capability 


Progresslndicator No 7 (see annex E) 





It may carry other information elements as well: See clause 5.2 and tables 5.1.2.3-2 to 5.1.2.3-5. 

The SDP answer is described in annex C. 

Handling of fallback information 

When the terminating AGCFA^GWhsiS knowledge that the fallback capability was requested in the Initial INVITE, and 
if no progress indicator No. 1 or No. 2 has been received from the DSS 1 side, tables 5.1.2.3-2 to 5.1.2.3-5 are 
applicable. 
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Coincident S and T reference point 

Table 5.1.2.3-2: Handling of BC fallback information Coincident S and T reference point 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


BearerCapability 

(unrestricted digital information with tones and 

announcements) 


BC 

(unrestricted digital information with tones and 

announcements) 


BearerCapability 
(speech or 3,1 kHz audio) 


BC 

(speech or 3,1 kHz audio) 


BearerCapability received in the PSTN XML 
attachment of the received INVITE request 
(speech or 3,1 kHz audio) 


NoBC 



The SDP answer is described in annex C. 

Table 5.1.2.3-3: Handling of HLC fallback information Coincident S and T reference point 



^200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


HighLayerCompatibility 


HLC 


HighLayerCompatibility received in first position in 
the PSTN XML attachment of the INVITE request 


No HLC 



The SDP answer is described in annex C. 



T reference point 



Table 5.1.2.3-4: Handling of BC fallback information T reference point 



^ 200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


BearerCapability 

(unrestricted digital information with tones and 

announcements) 


BC 

(unrestricted digital information with tones and 

announcements) 


BearerCapability 
(speech or 3,1 kHz audio) 


BC 

(speech or 3,1 kHz audio) 


BearerCapability 
(speech or 3,1 kHz audio) 
Progresslndicator. No. 5 


BC 

(speech or 3,1 kHz audio) 

p.i. No. 5 


BearerCapability received in the PSTN XML attachment 
of the INVITE request 
(speech or 3,1 kHz audio) 
Progresslndicator No. 5 


No BC (see note) 


NOTE: In this case, the fallback information coded in the PSTN XML attachment are not repeated if 
already sent in a previous backward message. 



The SDP answer is described in annex C. 

Table 5.1.2.3-5: Handling of HLC fallback information T reference point 



^200 OK INVITE 


^CONNECT 


PSTN XML attachment 


Content 


HighLayerCompatibility 


HLC 


HighLayerCompatibility 
Progresslndicator No. 5 


HLC 
Progress indicator No. 5 


No HighLayerCompatibility 


No HLC 



The SDP answer is described in annex C. 
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5.1.2.4 



Receipt of BYE/CANCEL 



Table 5.1.2.4-1 : Receipt of BYE/CANCEL 



BYE/CANCEL^ 


DISCONNECT ^ 


Reason header 


Cause information element 


cause No. x 


Cause value No. x 
(see notes 1 and 2) 


NOTE 1 : If the Reason value received in the Release message (BYE/CANCEL) is unknown in DSS 1 , the 

unspecified cause value of the class is sent. 
NOTE 2: Some supplementary services, such as CUG or UUS supplementary services, require the mapping 

of some cause values: see clause 5.2. 
NOTE 3: The location is coded '1010' network beyond interworking point 



The handling of the other parameters is described in clause 5.2. 



5.1.2.5 



Sending of BYE/4xx/5xx 



Table 5.1.2.5-1: Call clearing during call establishment 



^ BYE/4XX/5XX 


^DISCONNECT 

RELEASE 

RELEASE COMPLETE 

(see note 1) 


Reason header 


Cause information element 


cause No. x 


Cause value No. x 


NOTE 1 : In case of coincident S and T reference point, 5.2.5.3/Q.931 [54] describes how these messages are 

taken into account when they are received during call establishment. 
NOTE 2: If the cause value received in the DSS 1 message is unknown in ISUP, the unspecified cause value 

of the class is sent. 
NOTE 3: Some supplementary services, such as CUG or UUS supplementary services, require the mapping 

of some cause values: see clause 5.2. 



The handling of the other parameters possibly present in the Release message BYE or 4xx/5xx is described in 
clause 5.2. 



5.1.2.6 



Sending of the DSS1 INFO (Optional) 



If Overlap Signalling is supported between the AGCF/VGW and the terminating PES Application Server the Overlap 
Signalling method used, either the Multiples INVITES method or the IN-Dialog method as described within annex G 
and annex H is dependent on national or network operator option. 
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5.2.1.1 
5.2.1.1.1 



Notification received from tlie network 

Table 5.2.1 .1.1-1: HOLD notification 



INVITE/ UPDATE ^ 


NOTIFY ^ 


SDP: a=sendonly/inactive 


Notification indicator 
information element 




Notification description 


sendonly/inactive 


111 1001 
Remote hold 


sendreceive 


111 1010 
Remote retrieval 



5.2.1 .1 .2 Invocation at coincident S and T reference point 

Table 5.2.1.1.2-1: HOLD invocation 



^INVITE/UPDATE 


<r- Message received from the DSS 1 


SDP: a=sendonly/inactive 


sendonly/inactive 


HOLD 


sendreceive 


RETRIEVE 



5.2.1 .1 .3 Notification received at T reference point 

A HOLD notification may be received at T reference point in the active phase of the call. 

Table 5.2.1.1.3-1 : Receipt of a HOLD notification from a private network 



^INVITE/UPDATE 


^NOTIFY 


SDP: a=sendonly/inactive 


Notification indicator 
information element 




Notification description 


sendonly/inactive 


111 1001 
Remote hold 


sendreceive 


111 1010 
Remote retrieval 



5.2.1 .2 Actions at the outgoing AGCF/VGW 

5.2.1 .2.1 Notification received from the network 

Table 5.2.1.2.1-1 : Receipt of HOLD notification from the network 



^NOTIFY 


^INVITE/UPDATE 


Notification indicator information element 


SDP: a=sendonly/inactive 


Notification description 




111 1001 
Remote hold 


sendonly/inactive 


111 1010 
Remote retrieval 


sendreceive 



ETSI 



37 ETSI TS 1 83 036 V2.1 .1 (2009-01 ) 



5.2.1 .2.2 Invocation at coincident S and T reference point 

Table 5.2.1.2.2-1: HOLD invocation 



IVIessage received from 
the DSS 1 ^ 


INVITE/UPDATE^ 


SDP: a=sendonly/inactive 




HOLD 


sendonly/inactive 


RETRIEVE 


sendreceive 



5.2.1 .2.3 Notification received at T reference point 

A HOLD notification may be received at T reference point in the active phase of the call. 

Table 5.2.1.2.3-1 : Receipt of a HOLD notification from a private network 



NOTIFY^ 


INVITE / UPDATE^ 


Notification indicator 
information element 


SDP: a=sendonly/inactive 


Notification description 




111 1001 
Remote hold 


sendonly/inactive 


111 1010 
Remote retrieval 


sendreceive 



5.2.2 Connected Line Identification Presentation (COLP) / Connected Line 
Identification Restriction (COLR) 

5.2.2.1 Actions at the inconning AGCF/VGW 

If the Initial INVITE is received and the Supported header contains the "from-change" tag, then the 
P-Asserted-Identity in the 200 OK INVITE or UPDATE request and the changed From header in the UPDATE are sent 
as described in tables 5.2.2.1.1-1 and 5.2.2.1.1-2. 

5.2.2.1.1 Connected Line Identification Presentation (COLP) 

The AGCFA^GW shall sent first a 200 OK INVITE including an option tag "from-change" and after then an UPDATE 
request as shown in table 5.2.2.1.1-1 according the rules of RFC 4916 [50]. 
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200 OK and UPDATE is sent on the Mw interface 

Table 5.2.2.1.1-1 : Connected number interworking applies at Mw interface 



^ 200 OK INVITE 


^ UPDATE 


^CONNECT 


Connected number IE. 






Numbering plan 
identification 


Type of number 


No "from-change" tag in the 
supported header 
P-Asserted-ldentity containing the 
value saved from the P-Called- 
Party-ID header that was received 
in the INVITE request. 


No UPDATE 


No or invalid (see note 1) connected 
number information element 


No "from-change" tag in the 
supported header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


unknown 


Address digits 




No "from-change" tag in the 
supported header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


Subscriber number 


Address digits 




"from-change" tag in the supported 
header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


Userinfo of the changed From 
header derived from the 
Address digits in the format: sip: 
local-number-digits = Address 
digits; phone- 

context=xxxxxx@hostportion; 
user=phone (see note 2). 


ISDN/telephony 
numbering plan 
or 
Unknown 


National number 


Address digits 


"from-change" tag in the supported 
header 

P-Asserted-ldentity with a value, 
including the display name if 
previously stored during 
registration representing the 
terminating user indicated in the 
connected number. 


Userinfo of the changed From 
header derived from the 
Address digits in the format: sip: 
global -number-digits = Address 
digits@hostportion; 
user=phone. 


ISDN/telephony 
numbering plan 
or 
unknown 


international number 


Address digits 


NOTE 1 : Validity conditions of the connected number information element are defined in 5.5.2.3/Q.951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



If the "from-change" tag in the Supported header in the Initial INVITE is not received, then no UPDATE is sent. 

A P-Asserted-Identity header with the value saved from the P-Called-Party-ID header that was received in the request is 

contained in the 200 OK (INVITE). 

Connected subaddress 

If provided, the connected subaddress is transported in the changed From header field of the UPDATE request. 
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200 OK and UPDATE is sent on the Gm interface 

Table 5.2.2.1.1-2: Connected number interworking applies at Gm interface 



^ 200 OK INVITE 


^ UPDATE 


^CONNECT 


Connected number IE. 






Numbering plan 
identification 


Type of number 


No "from-change" tag in the 
supported header 


No UPDATE 


No or invalid (see note 1) connected 
number information element 


No "from-change" tag in the 
supported header 


No UPDATE 


ISDN/telephony 
numbering plan 
or 
Unknown 


unknown 


Address digits 




No "from-change" tag in the 
supported header 


No UPDATE 


ISDN/telephony 
numbering plan 

or 
Unknown 


Subscriber 
number 


Address digits 




"from-change" tag in the supported 
header 




ISDN/telephony 
numbering plan 
or 
Unknown 


National number 


Userinfo of the changed From 
header derived from the 
Address digits in the format: 
sip: local-number-digits = 
Address digits; phone- 
context=xxxxxx@hostportion; 
user=phone (see note 2) 


Address digits 




ISDN/telephony 
numbering plan 

or 
unknown 


international 
number 




Userinfo of the changed From 
header derived from the 
Address digits in the format: 
sip: global -number-digits = 
Address digits @hostportion; 
user=phone 


Address digits 


NOTE 1 : Validity conditions of the connected number information element are defined in 5.5.2.3/Q.951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



Connected subaddress 

If provided, the connected subaddress is transported in the changed From header field of the UPDATE request. 

5.2.2.1 .2 Connected Line Identification Restriction (COLR) 

Table 5.2.2.1.2-1 : Coding of the Privacy header field 



^200 OK INVITE 


^CONNECT 


Privacy header field 


Connected number 

information element 

Presentation indicator 


"id", "header", "user" 


Presentation restricted 


No Privacy header 


Absent 


"none" 


Presentation allowed 
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5.2.2.2 



Actions at the outgoing AGCF/VGW 



5.2.2.2.1 Connected Line Identification Presentation (COLP) 

NOTE: Depending on national regulations, some networks may define categories of subscribers that have the 
ability to override the presentation restriction and have the connected party's ISDN number, and 
subaddress information (if any) presented (e.g. the police). The ability to override the presentation 
restriction and the protocol to support such a service is a national matter. 

The option tag "from-change" is added to the supported header in the initial INVITE. 

Only one connected number information element is sent in the CONNECT message. 

If a 200 OK final response including the option tag "from-change" is received then T^jj^^ shall be started if Userinfo of 
P-Asserted-Identify is in the format of a tel URI and no Privacy (including Privacy value of none) is present. In this 
case the interworking as described in tables 5.2.2.2.1-2 and 5.2.2.2.1-3 applies. The 200 OK INVITE to a CONNECT 
shall be held up till the UPDATE containing the changed From and To information is received and timer T^jj^^ is 
running ELSE the 200 OK INVITE shall be mapped immediately as described within tables 5.2.2.2.1-1 and 5.2.2.2.1-2. 
At expiry of T^j^^ the 200 OK INVITE shall be mapped as described in table 5.2.2.2.1-2. 

If no P-Asserted-Identity header was received and no Privacy "id" or "header" was received in the 200 OK final 
response this is assumed as the originating user has not subscribed the COLP service. 

If the P-Asserted-Identity was received and in the format " unavailable @unknown.invalid" it is assumed that the 
originating user has subscribed the COLP service but the original P-Asserted-Identity was lost due to an interworking 
with an untrusted network. 

If several responses contain a P-Asserted-Identity header field, only the latest received P-Asserted-Identity header 
should be used for a Connected number sent in a CONNECT message to the calling user. 

Table 5.2.2.2.1-1 : COLP information sent to the calling user 



^CONNECT 


^200 OK INVITE 


COLP information sent to the calling 
user 


P-Asserted-ldentity 


Privacy header 


Supported header 


Connected number IE 
(see table 5.2.2.2.1-2) 


Userinfo in the format of a tel 
URI 


No Privacy 
present 
or 
Priv .value none 


No "from-change" 


Connected number IE 
(see table 5.2.2.2.1-3) 


Userinfo in the format of a tel 
URI 


No Privacy 
present 
or 
Priv .value none 


"from-change" 


Connected number IE 

Type of number Unknown 
Numbering plan Unknown 
Presentation ind. Presentation 

restricted 
Screening ind. Network provided 
Number digits No digit 


Userinfo not in the format of a 
tel URI 


id or header 


Value non- 
significant 


Not present 


Connected number IE 

Type of number Unknown 
Numbering plan Unknown 
Presentation ind. Not available due to 

interworking 
Screening ind. Network provided 
Number digits No digit 


unavailable@unknown. invalid 




Value non- 
significant 


No Connected number IE 


No P-Asserted-ldentity header 
field 


no Privacy 
present 


Value non- 
significant 



If the P-Asserted-Identity header is received at the AGCFA^GW it is assumed that the originating user subscribes the 
COLP supplementary service. 
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Table 5.2.2.2.1-2: Coding of the connected number information element 
according to the P-Asserted-ldentity header field 



^CONNECT 


^200 OK INVITE 


Connected number IE 


P-Asserted-ldentity 


Type of number (see note) 
National number 

International number 


userinfo 

sip: local-number-digits; phone-context=nat 
@hostportion; user=phone 

sip: global-number-digits@hostportion; 
user=phone 


Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 
Network provided 




Number digits derived from the userinfo. 
In case for global number and the country code is 
the same as the AGCF/VGW or line is located, the 
country code is removed from the number of the 
Type of number is set to "national number 




NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the 
number. 



Table 5.2.2.2.1-3: Coding of the connected number information element 
according to the changed From header 



^CONNECT 


^UPDATE 


Connected number IE 


From header 


Type of number (see note) 
National number 

International number 


userinfo 

sip: local-number-digits; phone-context=nat 
@hostportion; user=phone 

sip: global-number-digits@hostportion; 
user=phone 


Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 

User provided, not verified 




Number digits derived from the userinfo. 
In case for global number and the country code is 
the same as the AGCF/VGW or line is located, the 
country code is removed from the number of the 
Type of number is set to "national number 




NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 
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Connected subaddress 



Table 5.2.2.2.1-4: Sending of the connected subaddress 



^CONNECT 


^UPDATE 


Content 


Changed From isub parameter 


Privacy header 


Connected subaddress 
information element 


Connected subaddress address 
string 


absent or not "id" 


No connected subaddress 
information element 


Connected subaddress address 
string 


"id" or "header" 

or 

No connected number parameter 


NOTE: As a national option, the presentation restriction indication received in the connected number 
parameter can be overridden for specific calling access' categories. In such a case, the same 
actions are taken as if presentation allowed y\/as received. 



5.2.2.2.2 Connected line identification restriction (COLR) 

See table 5.2.2.2.1-1. 

5.2.3 Calling line Identification Presentation (CLIP) / Calling line 
Identification Restriction (CLIR) 

5.2.3.1 Actions at the incoming AGGF/VGW 

Table 5.2.3.1-1 : Mapping of SIP From/P-Asserted-ldentity/Privacy header fields to GLI parameters 



INVITE^ 


SETUPS 


P-Asserted-ldentity 


From header 


Privacy 


Coding of the calling 
party number 
information element 


Absent 


Value not significant 


No Privacy header 


No Calling number IE 


Absent 


Value not significant 


"Id" or "Header" or 
"user" 


see table 5.2.3.1-3 


User portion not in the 
format of ate! URI 


Value not significant 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


see table 5.2.3.1-2 


User portion not in the 
format of ate! URI 


Value not significant 


"Id" or "Header" or 
"user" 


see table 5.2.3.1-3 


User portion is in the 
format of ate! URI 


User portion is not in the 
format of a tel URI 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


see table 5.2.3.1-4 


User portion is in the 
format of ate! URI 


User portion is not in the 
format of a tel URI 


"Id" or "Header" or 
"user" 


see table 5.2.3.1-3 


The user portion of the P-Asserted-ldentity and the 
user portion of the From header are in the format of a 
tel URI and 

the user portion of the P-Asserted-ldentity is not equal 
to the user portion of the From header 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


The calling party number 
information element is 
repeated with one 
occurrence encoded 
according to 
table 5.2.3.1-4 and the 
other occurrence 
according to 
table 5.2.3.1-5 


The user portion of the P-Asserted-ldentity and the 
user portion of the From header are in the format of a 
tel URI and 

the user portion of the P-Asserted-ldentity is equal to 
the user portion of the From header 


No Privacy header or 
the header has other 
values than "Id" or 
"Header" or "user" 


see table 5.2.3.1-4 


User portion is in the 
format of ate! URI 


User portion is in the format 
of a tel URI 


"Id" or "Header" or 
"user" 


see table 5.2.3.1-3 
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If no P-Asserted-Identity header is received at the AGCFA^GW it is assumed that the terminating user does not 
subscribe the CLIP supplementary service. 

Table 5.2.3.1-2: Calling party number not presented due to interworking to the called user 



Calling party number IE 


Type of number 


Unknown 


Numbering plan identification 


Unknown 


Presentation indicator 


Not available due to interworking 


Screening indicator 


Network provided 


Number digits 


No digits 



Table 5.2.3.1-3: Calling party number not presented due to presentation restriction to the called user 



Calling party number IE 


Type of number 


Unknown 


Numbering plan identification 


Unknown 


Presentation indicator 


Presentation restricted 


Screening indicator 


Network provided 


Number digits 


No digits 



Table 5.2.3.1-4: Coding of the calling party number information element 
according to the P-Asserted-ldentity header field 



INVITE^ 


SETUPS 


P-Asserted-ldentity header 


Calling party number IE 


sip: local-number-digits; 

phone-context=nat @hostportion; user=phone 


Type of number (see note) 
National number 


sip: global-number-digits@hostportion; 
user=phone 


Type of number (see note) 
International number 




Numbering plan identification 

ISDN/Telephony numbering plan 


Presentation indicator 
Presentation allowed 


If the userinfo of the From header field is equal to the 
userinfo in the P-Asserted-ldentity 


Screening indicator 

User provided, verified and passed 


If the userinfo of the From header field is not equal to 
the userinfo in the and P-Asserted-ldentity 


Screening indicator 
Network provided 




Number digits are derived from user portion. 
In case for global number and the country code is the 
same as the AGCF/VGW or line is located, the country 
code is removed from the number of the Type of 
number is set to "national number" 


NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 
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Table 5.2.3.1-5: Coding of the calling party number information element 
according to the From header field 



INVITE^ 


SETUPS 


From header field 


Calling party number IE 


sip: local-number-digits; 

phone-context=nat @hostportion; user=phone 


Type of number (see note) 
National number 


sip: global-number-digits @hostportion; 
user=phone 


Type of number (see note) 
International number 




Numbering plan identification 

ISDN/Telephony numbering plan 




Presentation indicator 
Presentation allowed 




Screening indicator 

User provided, not verified 




Number digits are derived from user portion. 
In case for global number and the country code is the 
same as the AGCF/VGW or line is located, the country 
code is removed from the number of the Type of 
number is set to "national number" 


NOTE: As a network option, the type of number may be coded unknown when a prefix is added to the number. 



5.2.3.2 Actions at the outgoing AGCF/VGW 

Actions at the Gm interface 

Table 5.2.3.2-1 : Mapping CLI parameters to SIP header fields - Gm interface 



SETUPS 


INVITE^ 


Presentation 

Restriction 

Indicator 


P-Preferred-ldentity 
header field 


From header field: 


Privacy 

header 

field 


Privacy 
value 


Presentation 
restricted 


Addr-spec is derived 
from Calling Party 
Number parameter 
Address Signals 
(see note 1 ) 


Addr-spec is derived from Calling 

Party Number parameter Address 

Signals 

or (see note 2) 

"anonymous@anonymous. invalid" 


Y 


"id" and 

"header" 

and "user" 


Presentation 
restricted 

(see note 3) 


Default registered 
public identity 
associated with calling 
party is used 


unavailable@unknown. invalid 


Y 


"id" and 

"header" 

and "user" 


Absent 


Default registered 
public identity 
associated with calling 
party is used 


"unavailable@unknown. invalid" 


N/Y (see 
note 2) 


If present: 
"id" and 
"header" 

and "user" 


Allowed 


Addr-spec is derived 
from Calling Party 
Number parameter 
Address Signals 
(see note 1 ) 


Addr-spec is derived from Calling 
Party Number parameter Address 
Signals 
(see note 1 ) 


Y 


"none" 


NOTE 1 : Mapping CLI parameters to SIP header fields see table 5.2.3.2-3. 

NOTE 2: As network option. 

NOTE 3: Calling party number available but number digits are not included. 
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Actions at the Mw interface 



Table 5.2.3.2-2: Mapping CLI parameters to SIP header fields - Mw interface 



SETUPS 


INVITE^ 


Presentation 

Restriction 

Indicator 


P-Asserted-ldentity 
header field 


From header field 


Privacy 

header 

field 


Privacy 
value 


Presentation 
restricted 


Addr-spec: calling 
party number address 
signal is matched with 
one of the public user 
identities else if no 
matched the default 
public user identity is 
used 


Addr-spec is derived from Calling 

Party Number parameter Address 

Signals 

or (see note 2) 

"anonymous@anonymous. invalid" 


Y 


"id" and 

"header" 

and "user" 


Presentation 
restricted 

(see note 3) 


Addr-spec is the 
default public user 
identity 


unavailable@unknown. invalid 


Y 


"id" and 

"header" 

and "user" 


Absent 


Addr-spec is the 
default public user 
identity 


"unavailable@unknown. invalid" 


N/Y 
(see note 2) 


If present: 
"id" and 
"header" 

and "user" 


Allowed 


Addr-spec: calling 
party number address 
signal is matched with 
one of the public user 
identities else if no 
matched the default 
public user identity is 
used (see note 1) 


Addr-spec is derived from Calling 
Party Number parameter Address 
Signals (see note 1) 


Y 


"none" 


NOTE 1 : Mapping CLI parameters to SIP header fields see table 5.2.3.2-3. 

NOTE 2: As network option. 

NOTE 3: Calling party number available but number digits are not included. 
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Table 5.2.3.2-3: Mapping CLI parameters to SIP header fields at the Gm interface 



SETUPS 


INVITE^ 


Calling party number IE 


From Header Field 


P-Preferred-ldentity 


Type of number 


Numbering plan 
identification 






No or invalid (see note 1) 
calling party number 
information element 


See table 5.2.3.2-1 


See table 5.2.3.2-1 


National number 


ISDN/telephony 
numbering plan 
or 
Unknown 


The userinfo is derived from 
the address string of the 
calling party number IE 
sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


International 
number 


The userinfo is derived from 
the address string of the 
calling party number IE 

sip: global-number-digits 
@hostportion; 

user=phone 


The userinfo is derived from 
the address string of the calling 
party number IE 
sip: global-number-digits 

@hostportion; 
user=phone 


Subscriber 


The userinfo is derived from 
the address string of the 
calling party number IE 
sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


Unknown 


The userinfo is derived from 
the address string of the 
calling party number IE 

sip: local-number-digits; 
phone- 

context=xxxxxx@hostporti 

on; user=phone 

(see note 2) 


An attempt is made to match 
the address string of the calling 
party number IE to one of the 
calling party's registered public 
identities. If no match is 
determined, a default 
registered public identity is 
used. 


NOTE 1 : Validity conditions of the calling party number information element are defined in 3.5.2.2.1/Q.951 [30]. 
NOTE 2: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 
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Table 5.2.3.2-4: Mapping CLI parameters to SIP header fields at the Mw interface 



SETUPS 


INVITE^ 


Calling party number IE 


From Header Field 


Type of number 


Numbering plan 
identification 




No or invalid (see note 1) 
calling party number 
information element 


See table 5.2.3.2-2 


National number 


ISDN/telephony 
numbering plan 
or 
Unknown 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx@hostportion; 
user=phone (see note 3) 


International 
number 


The userinfo is derived from the address string of the calling 

party number IE 

sip: global-number-digits @hostportion; user=phone 


Subscriber 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx @hostportion; 
user=phone (see note 3) 


Unknown 


The userinfo is derived from the address string of the calling 
party number IE 

sip: local-number-digits; phone-context=xxxxxx@hostportion; 
user=phone (see note 3) 


NOTE 1 : Validity conditions of the calling party number information element are defined in 3.5.2.2.1/Q.951 [30]. 

NOTE 2: When the AGCF receives an SETUP with a Calling party number that matches one of the registered 

public user identities, the AGCF will insert this public user identity in the P-Asserted-ldentity as a result 
of applying the procedures defined for a UE and the P-CSCF. When the AGCF receives an SETUP with 
a Calling party number that does not match one of the registered public user identities, or the SETUP 
does not contain a Calling party number, the AGCF will insert the registered public user identity in the 
P-Asserted-ldentity header. 

NOTE 3: The combination of dialled digits and phone-context parameter shall globally unique in the network as 
defined in RFC 3966 [47]. 



5.2.4 Conference calling (CONF) 

This service is for further study. 

5.2.5 Communication Diversion Services (CDIV) 

As a network option the Activation, Deactivation and Interrogation of call forwarding services is performed using 
service code commands as described in EN 300 207-1 [34] (ISDN; Diversion supplementary services) and 
EN 300 196-1 [25] (ISDN; Generic functional protocol for the support of supplementary services) 

NOTE: These messages are mapped to the regarding PSTN XML documents described in clause 4.9 of 
TS 183 004 [8] and are sent via the Ut-interface to the AS. 

5.2.5.1 Actions at the Outgoing AGCF/VGW 

5.2.5.1 .1 Reception of a "call is diverting" notification 

According to TS 183 004 [8], the 181 Being Forwarded may be received. 

5.2.5.1 .1 .1 First diversion 

The latest history-entry, representing the diverted-to -number, contained in the History-Info header is stored. 
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A notification of diversion is sent to the calling user as shown in table 5.2.5.1.1.1-1. 

Table 5.2.5.1.1.1-1: First diversion: notification of diversion sent to the calling user 



^DSS 1 message 
(see note) 


^181 (Call Being Forwarded) 




Notification indicator 
information element 




Call is diverting 




NOTE: If no message is to be sent, the notification indicator information element is sent in a NOTIFY message. 



5.2.5.1 .1 .2 Subsequent diversion 

The latest history-entry, represents the diverted-to -number, contained in the History-info header field is stored if the 
URI of the history-entry is different to the previous received and stored diverted-to number (i.e. the latest received 
diverted-to number replaces the one received previously). 

If notification of diversion is not allowed, no specific interworking action is required towards the calling user. 

If notification of diversion is allowed, table 5.2.5.1.2-1 is applicable. 

Table 5.2.5.1 .1 .2-1 : Subsequent diversion: notification of diversion sent to the calling user 



^DSS 1 message 
(see note 1) 


^181 Call Being Forwarded 




Notification indicator IE 


No notification sent 


History-Info header: latest history-entry 


Call is diverting 


cause=487 (Deflection during alerting) 

or 

cause=408 (No reply) 


No notification sent 


Other cause values 


NOTE 1 : The determination of the DSS 1 message sent upon 181 Being Forwarded is described in clause 5.1 . If no 

message is to be sent, the notification indicator information element is sent in a NOTIFY message. 
NOTE 2: The latest received diverted-to number replaces the one received previously. 



5.2.5.1 .2 Evaluation of History-Info header 

If a backward message (provisional response or 200 OK) is received containing a History-Info header and there is no 
privacy header is included in the URI of the latest history-entry: 

• it has been determined, according to TS 183 004 [8], that the notification of diverted-to number is allowed, a 
redirection number information element is sent to the calling user as shown in 

table 5.2.5.1.2-1; 

• if a Privacy=history is included in the latest history-entry, no information is sent to the calling user. 
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Table 5.2.5.1.2-1 : Notification of tlie diverted-to number 



^DSS 1 message (see note 1) 


Redirection number parameter 
stored in the originating entity 


^181, 180 or 200 OK 


Redirection number 
information element 


History-Info header: 
Latest History-entry 


Type of number 

According to the nature of address 
indicator (see note 2) 
Numbering plan identification 
ISDN (telephony) numbering plan 
Presentation indicator 

Presentation allowed 
Number digits 
Digits received in the userinfo 


Nature of address indicator 

National number s\p: local-number-digits; 

phone-context=nat @hostportion; 

user=phone 

International number s\p: global-number- 

digits@hostportion; 

user=phone. 

Numbering plan indicator 

ISDN (telephony) numbering plan 

Address signal: User portion received in 

the URI; if the country code of the URI: In 

case for global number and the country 

code is the same as the AGCF/VGW or line 

is located, the country code is removed 

from the number of the Type of number is 

set to "national number". 


Mw or Gm Interface 

No Privacy header included 


Type of number 

Unknown 

Numbering plan identification 

Unknown 

Presentation indicator 

Presentation restricted 
Number digits 
Not includedDigits 
or no Information Element is sent 


Nature of address indicator 

National number s\p: local-number-digits; 

phone-context=nat @hostportion; 

user=phone 

International number s\p: global-number- 

digits@hostportion; 

user=phone. 

Numbering plan indicator 

ISDN (telephony) numbering plan 

Address signal 

User portion received in the URI. In case for 

global number and the country code is the 

same as the AGCF/VGW or line is located, 

the country code is removed from the 

number of the Type of number is set to 

"national number" 


Mw Interface 

Privacy header included and 
the value is equal to 
"history" 


Type of number 

Unknown 
Numbering plan identification 

Unknown 
Presentation indicator 
Number not available due to 
interworking 
Number digits 

Not included 
(see note 3) 
or no Information Element is sent 


No redirection number stored 


Mw or Gm Interface 

No History-Info header 
received 


NOTE 1 : The determination of the DSS 1 message sent upon the SIP backward message is described in 

clause 5.1 . If no message is to be sent, the redirection number information element is sent in a NOTIFY 
message. 

NOTE 2: As a network option, the type of number may be coded unknown. 

NOTE 3: This redirection number is sent if e 181 was received and no History-Info header was included in any 
response. 



5.2.5.1.3 



Procedures at the T reference point 



When the AGCFA^GW receives a SETUP containing a Facility information element including a 
DivertingLegInformation2 invoke component, an INVITE is sent containing a History-Info header. 
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Table 5.2.5.1.3-1: Mapping of the DivertingLeglnformation2 
invoke component into the History-Info header 



SETUP ^ 


INVITE ^ 


DivertingLeglnformation2 


History-Info header 


diversionCounter 


1 


History Index 
Number of diversions are 
sown due to the number 
of Index Entries 
(see note) 


Index for divertingNr = 1 
Index for Request URI = 1 .1 


2 


Index for originalCalledNr = 1 
Index for divertingNr =1.1 
Index for Request URI = 1.1.1 


N 


Index for originalCalledNr = 1 
Placeholder History entry with Index = 
1.1 

Fill up 

Index for divertingNr = 1 +[(N-1 )*". 1 "] 

Index for Request URI 

= 1+N*".1"(e.g. N=3^ 1.1.1.1) 


diversionReason 


unknown 


Cause parameter in latest History entry 


"404" 


cfu 


"302" 


cfb 


"486" 


cfnr 


"408" 


cdAlerting 


"487" 


cdlmmediate 


"480" 


divertingNr 


2"d latest entry 


originalCalledNr 


first entry 


NOTE: The History index is generated according the rules in subclause 4 in RFC 4244 [45]. 



When the AGCFA^GW receives a 18x provisional or 200 OK final response, the AGCFA^GW sends a FACILITY, 
ALERTING or CONNECT message. The value of the Privacy parameter in the latest contained History-Info header is 
mapped in a DivertingLeglnformationS invoke component. A FACILITY is only sent, if the 181 contains a 
History-Info header. 

Table 5.2.5.1.3-2: Mapping of the value of the Privacy parameter in latest History Entry 
into the DivertingLeglnformation2 invoke component 



^ DSS1 Message 


^ SIP Message 


DivertingLeglnformationS: 
presentationAllowedlndicator 


History-Info header: 

Privacy parameter in the latest History entry 


FACILITY 


true 


181 (Being Forwarded) 


No Privacy parameter 


false 


Privacy: "history" 


ALERTING 


true 


180 (Ringing) 


No Privacy parameter 


false 


Privacy: "history" 


CONNECT 


true 


200 OK (INVITE) 


No Privacy parameter 


false 


Privacy: "history" 



5.2.5.2 



Actions at the incoming AGCF/VGW 



5.2.5.2.1 



Interworking at the AGCF/VGW where a call is diverted within or beyond the 
private ISDN (T reference point) 



When the AGCFA^GW receives a DSSl PROGRESS or ALERTING message, a Provisional Response is sent. When a 
FACILITY message is received containing a DivertingLeglnformationl invoke component, a 181 Provisional Response 
is sent. 

If the DSSl FACILITY, PROGRESS or ALERTING message contains a DivertingLeglnformationl invoke component 
Information Element, a History-Info header is sent in concerned response. The mapping is described in table 5.2.5.2.1-1 
and table 5.2.5.2.1-2. 
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Table 5.2.5.2.1-1: Interworking of DSS1 messages 



<r- SIP Message 


^ DSS1 Message 


180 (Ringing) 


ALERTING 


181 (Being forwarded) 


FACILITY 


183 (Session Progress) 


PROGRESS 



Table 5.2.5.2.1-2: Mapping of the DivertingLeglnformationI invoke component 

into History-Info header 



^SIP Message 18x 


^ ALERTING, FACILITY, PROGRESS 


History-Info header 


DivertingLeglnformationI 


Latest History Entry: 
cause-param = 
"cause" EQUAL 
Status-Code 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Privacy parameter in 
the latest History Entry 




subscriptionOption 


noNotification 


"History" 


notificationWithoutDivertedToNr 


No Privacy parameter 


notificationWithDivertedToNr 


latest Hi-targeted-to URI 


divertedToNumber 



If the DivertingLeglnformationI invoke component: subscriptionOption is coded noNotification, no 
History-Info header is sent in the response message. For the same circumstance, a FACILITY message is not 
interworked. 

In addition, if the ALERTING, FACILITY or CONNECT message contains a DivertingLeglnformationS invoke 
component. The Privacy parameter escaped in the Hi-target-to-uri representing the diverted-to user in the History-Info 
header (last entry) is set to the value as described in table 5.2.5.2.1-3. 

Table 5.2.5.2.1-3: Mapping of the value of the Privacy parameter in latest History Entry 
into the DivertingLeglnformationS invoke component 



<r- SIP Message 


^ DSS1 Message 


History-Info header: Privacy parameter in the latest 
History entry 


DivertingLeglnformationS: presentationAllowedlndicator 


180 (Ringing) 


No Privacy parameter 


ALERTING 


true 


Privacy: "history" 


false 


181 (Being forwarded) 


No Privacy parameter 


FACILITY 


true 


Privacy: "history" 


false 


200 OK (INVITE) 


No Privacy parameter 


CONNECT 


true 


Privacy: "history" 


false 



5.2.5.2.2 Interworking at the coincident S and T reference point where a diverted call is 

presented 

Table 5.2.5.2.2-1 : Redirecting number information element sent to the called user 



INVITE^ 


SETUPS 


History-Info header 


Content 


index = 1.1 


Redirecting number information element 
(see table 5.2.5.2.2-2) 


index > 1.1 


1^* Redirecting number information element 
(see table 5.2.5.2.2-2) 

2"^^ Redirecting number information element 
(see table 5.2.5.2.2-3) 
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Table 5.2.5.2.2-2: Coding of the first Redirecting number information element 



History-Info header 


Redirecting number 


first entry; index=1 


information element 


No Privacy header included 


Type of number (see notes 1 and 5) 
Numbering plan identification (see notes 2 
and 5) 

Presentation indicator: presentation allowed 
Reason of diversion: (see note 3) 
Number digits: (see notes 4 and 5) 


Privacy=history included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: presentation 

restricted 

Reason of diversion: (see note 3) 

No Number digits 


First entry not included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: number not available 

due to interworking 
Reason of diversion: (see note 3) 
No Number digits 


NOTE 1 : National if the URI is coded as follows sip: local-number-digits; phone-context=nat 

@hostportion; user=phone or 

international \i the URI is coded as follows sip: global -number-digits @hostportion; 

user=phone 
NOTE 2: ISDN numbering plan. 
NOTE 3: If the index of the latest history-entry is set to 1 .1 : as received in the cause parameter in 

the latest history-entry. 

If the index of the latest history-entry is greater than 1.1: unknown. 
NOTE 4: User portion as received in the second last URI; global-number-digits: if the country 

code of the URI is the same as the country where the user or line is located, the country 

code is removed from the user portion. 
NOTE 5: As a network provider option the prefix is added to the number. In this case the 

Numbering plan identification and the Type of number are coded unknown. 



ETSI 



53 



ETSI TS 183 036 V2.1.1 (2009-01) 



Table 5.2.5.2.2-3: Coding of the second Redirecting number information element (if any) 



History-Info header 


Redirecting number 


second last history-entry 


information element 


No Privacy header included 


Type of number (see notes 1 , 5) 
Numbering plan identification (see notes 2, 

5) 

Presentation indicator: presentation allowed 
Reason of diversion: (see note 3) 
Number digits: (see notes 4 and 5) 


Privacy=history included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: presentation 

restricted 

Reason of diversion: (see note 3) 

No Number digits 


First entry not included 


Type of number: unknown 

Numbering plan identification: unknown 

Presentation indicator: number not available 

due to interworking 
Reason of diversion: (see note 3) 
No Number digits 


NOTE 1 : -National if the URI is coded as follows sip: local-number-digits; phone-context=nat 

@hostportion; user=phone or 

- international \i the URI is coded as follows sip: global -number-digits @hostportion; 

user=phone. 
NOTE 2 : ISDN numbering plan. 

NOTE 3: As received in the cause parameter of the index of the latest history-entry. 
NOTE 4: User portion as received in the second last URI; global-number-digits: if the country 

code of the URI is the same as the country where the user or line is located, the country 

code is removed from the user portion. 
NOTE 5: As a network provider option the prefix is added to the number. In this case the 

Numbering plan identification and the Type of number are coded unknown. 



Table 5.2.5.2.2-4: Mapping of cause parameter in the history-entry 
to reason of diversion 



Cause parameter 


Reason of diversion 


unknown 


"404" 


Unknown 


unconditional 


"302 " 


Call forwarding unconditional 


User Busy 


"486" 


Call forwarding busy 


No reply 


"408" 


Call forwarding no reply 


Deflection during alerting 


"487" 


Call deflection during alerting 


Deflection immediate response 


"480" 


Call deflection immediate response 


Mobile subscriber not reachable 


"503" 


Unknown 



5.2.5.2.3 Interworking at the AGCF/VGW where a diverted call is presented to a private 

ISDN (T Reference point) 

When the AGCFA^GW receives an INVITE, a SETUP is sent on the network/user interface. If the INVITE contains a 
History-Info header, the History-Info header is mapped into a DivertingLegInformation2 invoke component. The 
History-Info header is stored in the AGCFA^GW. 
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Table 5.2.5.2.3-1 : Mapping of the History-Info header into the 
DivertingLeglnformation2 invoke component 



INVITE ^ 


SETUP ^ 


History-Info header 


DivertingLeglnformation2 


The number of dots in the latest index value represents the 
diversionCounter value 


diversionCounter 


cause-param = "cause" 
EQUAL Status-Code in 
latest History entry 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


2"d latest entry 


divertingNr 


first entry 


originalCalledNr (see note) 


NOTE: This element is not sent, if the diversionCounter is sent with the value 1 . 



As a response to this call setup, three possibilities are applicable: 

a) No further diversion occurs 

When a ALERTING, PROGRESS or CONNECT is received, the messages are interworked on a basic call 
base. The stored History-Info header received in the previous received INVITE is included in the Provisional 
Response or 200 OK INVITE. A Privacy parameter with value "history" is escaped in the last entry 
representing the diverted to user. 

b) A call diversion in the private network 

When a ALERTING, PROGRESS or FACILITY is received containing a DivertingLeglnformationl invoke 
component, the stored History-Info header received in the previous received INVITE is included in the 
Provisional Response and a history entry shall be added, interworked from the received 
DivertingLeglnformationL The sent History-Info header is stored in the AGCFA^GW, the previous stored 
History-Info header is overwritten. 

Table 5.2.5.2.3-2: Mapping of the DivertingLeglnformationl 
invoke component into added history entry 



^SIP IVIessage 18x 


^ ALERTING, FACILITY, PROGRESS 


History-Info header 


DivertingLeglnformationl 


Added (latest) History 
Entry: cause-param = 
"cause" EQUAL 
Status-Code 


"404" 


diversionReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Privacy parameter in 
the added (latest) 
History Entry 




subscriptionOption 


noNotification 


"History" 


notificationWithoutDivertedToNr 


No Privacy parameter 


notificationWithDivertedToNr 


Added (latest) Hi-targeted-to URI 


divertedToNumber 



If the DivertingLeglnformationl invoke component: subscriptionOption is coded noNotification, no History-Info 
header is sent in the response message. For the same circumstance, a FACILITY message is not interworked. 

c) A further call diversion beyond the private network 

In addition, if the ALERTING, FACILITY or CONNECT message contains a DivertingLeglnformationS 
invoke component. The Privacy parameter escaped in the Hi-target-to-uri representing the diverted-to user in 
the History-Info header (last entry) is set to the value as described in table 5.2.5.2.1-3. 
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5.2.5.2.4 Interworking at the AGCF/VGW where partial rerouting is requested from a 

private ISDN (T Reference point) 

After the INVITE was sent, when a FACILITY containing the CallRerouteing invoke component is received, a 
302 (Moved Temporarily) is sent. The callcdAddrcss element of the CallRerouteing invoke component is mapped 
into the URI of the Contact header. If the CallRerouteing invoke component: subscriptionOption is coded 
noNotification, no History-Info header is sent in the 302 response message. 

Table 5.2.5.2.4-1 : Mapping of the CallRerouteing invoke component 
into 302 (Moved Temporarily) 



^ 302 (Moved Temporarily) 


^ FACILITY 




CallRerouteing invoke component 


History-Info header: 
Last History Entry: 
cause-param = "cause" 
EQUAL Status-Code 


"404" 


rerouteingReason 


unknown 


"302" 


cfu 


"486" 


cfb 


"408" 


cfnr 


"487" 


cdAlerting 


"480" 


cdlmmediate 


Contact header 


URI 


calledAddress 


History-Info header: 
History Index 
Number of diversions 
are sown due to the 
number of Index Entries 
(see note) 


Index for lastRerouteingNr 

= 1 

Index for calledAddress = 

1.1 


rerouteingCounter 


1 


Index for To header = 1 

Index for lastRerouteingNr 

URI = 1.1 

Index for calledAddress = 

1.1.1 


2 


Index for To header = 1 
Placeholder History entry 
with Index = 1.1 

Fill up 

Index for lastRerouteingNr 
URI = 1+[(N-1)*".1"] 
Index for calledAddress 
= 1+N*".1"(e.g. N=3^ 
1.1.1.1) 


N 


PSTN XML body 


BearerCapability 


q931lnfoElement 


Bearer Capability 


LowLayerCompatibility 




Low layer compatibility 


HighLayerCompatibility 




High layer compatibility 


User-to-User header 




User-user information 


History-Info header: 2"^ latest entry 


lastRerouteingNr 


History-Info header: 
Privacy parameter in 
the last History Entry 


No History-Info header 


subscriptionOption 


noNotification 


"History" 




notificationWithoutDivertedToNr 


No Privacy parameter 




notificationWithDivertedToNr 


No mapping (see note) 


callingPartySubaddress 


NOTE: The calling subaddress is contained in the From header of the original INVITE. 



NOTE: Appropriate handling of the mapped information in the 302 have to be described in the PSTN/ISDN 
simulation service specification TS 183 004 [8] Communication diversion service. The History-Info 
header contained in the 302 is not used. Currently only the calledAddress in the Contact header is used. 

5.2.6 MCID 

5.2.6.1 Actions at the Outgoing AGCF/VGW 

There is no interworking requirement relating to the Malicious Call Identification (MCID) supplementary service. 
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5.2.6.2 Actions at the incoming AGCF/VGW 

There is no interworking requirement relating to the MaHcious Call Identification (MCID) supplementary service. 

Invocation of the service 

To invoke the MCID supplementary service, the called user shall send a McidRequest invoke component carried by a 
Facility information element in a FACILITY message. This invocation can only be sent during the Active state (NIO), 
during the Disconnect Indication state (N12) the invocation is not successful. 

To indicate that the service invocation has been accepted, the network shall send a McidRequest return result 
component carried by a Facility information element in a FACILITY message. 

These messages are mapped to a relNVITE as described in clause 4.5.2.12.1 of TS 183 016 [46] and are sent to the AS. 

Table 5.2.6.2-1 : MCID request 



^ INVITE 


^ FACILITY 


XML mcid 
request 

McidRequestlndicator="1 " (network 
operator option) 


McidRequest 



5.2.7 Explicit Communication Transfer (ECT) 
5.2.7.1 Actions at the Outgoing AGCF/VGW 

For this service, the separation "incoming call" and "outgoing call" does not apply. 

This clause describes the interworking at the AGCFA^GW (i.e. the exchange where the served user is connected to). To 
simulate ECT in the IMS, the Consultative Transfer is applicable. 

5.2.7.1 .1 Coincident S and T reference point 

5.2.7.1 .1 .1 Service invocation 

The invocation of ECT in the alerting state should be rejected by the AGCFA^GW. 

Table 5.2.7.1.1.1-1: ECT invocation 



IVIessage received 
from the served user (user A) 


REFER 


FACILITY^ 

Facility information element 

EctExecute invoke component 

or 

ExplicitEctExecute invoke 

component 


The request URI shall contain the SIP URI of the transferee as 
received in the Contact header field 

The Refer-To header field shall indicate the public address of the 

transfer Target. 

A Replaces header field parameter shall be added to the Refer-To 

URI together with a Require=replaces header field parameter. 

Method=INVITE 



The ECT procedures are performed by the Application Server and described in TS 183 029 [36]. As a network provider 
option: The REFER may be interworked in a relNVITE to the Transferee and to the Transfer target. These special 
REFER handling procedures are described in the TS 183 028 [32]. 
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5.2.7.1 .2 T reference point 

5.2.7.1 .2.1 Service invocation 

Receipt of a notification from the access: 

Table 5.2.7.1.2.1-1 : Receipt of a notification from the access 



Message received from the access 




FACILITY^ 

Facility information element 




Ectlnform invoke component 
alerting 


No mapping 


FACILITY^ 

Facility information element 

Ectlnform invoke component 

active 

redirectionNumber (see note) 




Facility information element (see note) 
SubaddressTransfer invoke component 


No mapping 


NOTE: The Access transport parameter is not interworked sent if the 
SubaddressTransfer invoke component is received. 



5.2.7.2 Actions at the inconning AGCF/VGW 

For this service, the separation "outgoing call" and "incoming call" does not apply. 

This clause describes the interworking at the 0/I-AGCFA^GW (i.e. the AGCFA^GW where the remote user(s) is(are) 
connected to). 

5.2.7.2.1 Coincident S and T reference point 

5.2.7.2.1 .1 Messages received from the network 

5.2.7.2.1 .1 .1 Receipt of an INVITE/UPDATE message 

The ECT simulation service is performed as described in TS 183 029 [36] with the additions and clarifications 
described in TS 183 028 [32] in special REFER handling procedures. 

Upon receipt of an INVITE or UPDATE: 

a) INVITE/UPDATE 

b) INVITE/UPDATE 

a) relNVITE 

NOTE: This interworking is applicable to the user in "active call state, call held auxiliary state" when the 
corresponding remote ECT user is in alerting state. 
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Table 5.2.7.2.1 .1.1-1: INVITE/UPDATE 



Message received from the 




network 






INVITE -> 


No mapping 


No mapping 


NOTE: This can only occur in case of interaction of ECT with ECT. 



b) relNVITE 

NOTE: This interworking is applicable to the user in "active call state, call held auxiliary state" or "active call 
state, idle auxiliary state" or "call delivered state" when the corresponding remote ECT user is in 
answered state. 

Table 5.2.7.2.1.1.1-2: INVITE/UPDATE 



INVITE ^ 




INVITE 


P-Asserted-ldentity 
Privacy absent or not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note 2) 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: Other cases: 

- no subaddress in the relNVITE; or 

- Privacy header value "id"; or 

- no P-Asserted-ldentity in the relNVITE. 



Table 5.2.7.2.1.1.1-3: INVITE/UPDATE 



INVITE/UPDATE not completing 
a 




Call transfer, alerting 
notification 






INVITE/UPDATE -> 
P-Asserted-ldentity (see note 2) 


No mapping 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: The P-Asserted-ldentity may be absent. 



5.2.7.2.1 .1 .2 Receipt of a UPDATE message for a call in alerting phase 

This clause appHes only for a call in alerting phase. 
One case is possible: 
• UPDATE. 
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Upon receipt of such a message, one case is possible: 

Table 5.2.7.2.1.1.2-1: UPDATE 
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UPDATE ^ 






P-Asserted-ldentity, Privacy 
header absent or not "id". 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note 2) 


No mapping 


NOTE 1 : This can only occur in case of interaction of ECT with ECT. 
NOTE 2: Other cases: 

no subaddress in the UPDATE; or 
- Privacy header value "id"; or 

no P-Asserted-ldentity present in the UPDATE. 



Table 5.2.7.2.1 .1.2-2: UPDATE 



UPDATE not completing a 
call-transfer-alerting notification 




UPDATE^ 
P-Asserted-ldentity 


No mapping 



5.2.7.2.2 
5.2.7.2.2.1 



T reference point 

Service invocation: Messages received from the network 



5.2.7.2.2.1 .1 Receipt of an INVITE/UPDATE 

Upon receipt of an INVITE or UPDATE, two cases are possible: 

a) INVITE. 

b) INVITE. 

a) INVITE 

NOTE 1: This interworking is applicable to the user in "active call state, call held auxiliary state" when the 
corresponding remote ECT user is in alerting state. 

b) INVITE 

NOTE 2: This interworking is applicable to the user in "active call state, call held auxiliary state" or "active call 
state, idle auxiliary state" or "call delivered state" when the corresponding remote ECT user is in 
answered state 
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Table 5.2.7.2.2.1.1-1: INVITE/UPDATE 



INVITE/UPDATE ^ 






P-Asserted-ldentity 

Privacy header absent or value is 

not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note) 


No mapping 


NOTE: Other cases: 

- no subaddress in the relNVITE; or 

- Privacy header value "id"; or 

- no P-Asserted-ldentity present in the relNVITE. 



5.2.7.2.2.1.2 
One case is possible: 
• UPDATE. 
a) UPDATE 



Receipt of a UPDATE for a call in alerting phase. 



Table 5.2.7.2.2.1.2-1: UPDATE 



UPDATE ^ 






P-Asserted-ldentity, Privacy 
header absent or value not "id" 

Connected Subaddress 
information element as isub 
parameter in the P-Asserted- 
ldentity 


No mapping 




Other cases 
(see note) 


No mapping 


NOTE: Other cases: 

- No subaddress in the UPDATE; or 

- Privacy header value "id"; or 

- No P-Asserted-ldentity present in the UPDATE. 



5.2.8 Subaddressing (SUB) 



The Sub-address (SUB) service allows the called (served) user to expand his addressing capacity beyond the one given 
by the E.164 user number. Subaddressing (SUB). 

The coding rules according RFC 3966 [47] are not supporting the Type of subaddress (NSAP and user specified) as 
defined in ISDN (Q.931 [54]). Only the NSAP Type is mapped. 

The called party subaddress information element received from the access in the SETUP message is transported in the 
in the isub parameter of the To header of the INVITE (see RFC 3966 [47]). 
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5.2.8.1 



Actions at the Outgoing AGCF/VGW 



Table 5.2.8.1-1 : SIP Header information for subaddressing mapping 
at the l-AGCF/VGW contained in the INVITE 



SETUP ^ 


INVITE ^ 


Called party sub-address (NSAP) 


To header isub parameter 

Called party subaddress address string 


Calling party sub-address (NSAP) 


From header isub parameter 

Calling party subaddress address string 


NOTE: The subaddress with Type of subaddress "User specified" is not transferred 



Table 5.2.8.1-2: SIP Header information for subaddressing mapping 
at the l-AGCF/VGW contained in the 200 OK INVITE 



^ CONNECT 


^ UPDATE 


Connected party sub-address (NSAP) 


From header isub parameter 
Connected subaddress address string 


NOTE: The subaddress with Type of subaddress "User specified" is not transferred 



5.2.8.2 



Actions at the incoming AGCF/VGW 



The called party subaddress information element received in the isub parameter of the To header of the INVITE (see 
RFC 3966 [47]) is transferred transparently in the SETUP message. The number type value is a network option, NSAP 
is recommended. 

Table 5.2.8.2-1 : Sending of the called party subaddress (SUB) 



INVITE^ 


SETUPS 


To header isub parameter 


Content 


Called party subaddress address string 


Called party subaddress information element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



Table 5.2.8.2-2: Sending of the calling party subaddress (SUB) 



INVITE^ 


SETUPS 


From header isub parameter 


Content 


Calling party subaddress address string 


Calling party subaddress information element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



Table 5.2.8.2-3: receiving of the connected subaddress (SUB) 



^ UPDATE 


^ CONNECT 


From isub parameter 


Content 


Connected party subaddress address string 


Connected party subaddress information 
element 


NOTE: The number type "NSAP" is recommended; other value is a network option. 



5.2.9 Closed User Group (CUG) 



A XML element containing the identification of the closed user group transferred in the INVITE between two AS is 
described in the clause 4.9.2 of TS 183 054 [28]. 



ETSI 



62 



ETSI TS 183 036 V2.1.1 (2009-01) 



5.2.9.1 



Actions at the Outgoing AGCF/VGW 



CUG checks at the originating AppHcation Server and determination of the type of call request in correlation with the 
CUG information received from the calling user in the SETUP message and the CUG attributes of the calling user are 
described in table 4, ETS 300 138-1 [21]. 

Invocation of Closed User Group 

Table 5.2.9.1-1 : Invocation of Closed User Group 



SETUPS 


INVITE^ 


Facility CUGCallOperation invoke 


XML Gug 

cugCallOperation 


outgoingAccessRequest 


outgoingAccessRequest 


cUGIndex 


cuglndex 



A rejection indication may be received in a 500 Server Internal Error. 

Table 5.2.9.1-2: Receipt of a rejection indication 



^DISCONNECT 


<r- Final Response 


Cause information element Return error component 


Response code 


Implicit request: 
Cause value No. 29 
Facility rejected 
Explicit request: 

Cause value No. 29 
Facility rejected 


No return error component 

Return error value #19 
incomingCallsBarredWithinCUG 


603 


Implicit request or not CUG request: 
Cause value No. 87 
User not member of CUG 
Explicit request: 
Cause value No. 29 
Facility rejected 


No return error component 

Return error value #20 
userNotMemberOfCUG 


403 


Implicit request: 

Normal handling of the cause value 

See 5.1 

Explicit request: 

Normal handling of the cause value 

See 5.1 


No return error component 

Return error value #8 
basicServiceNotProvided 


Other Response code 


NOTE: The above table provides examples of mapping. Another example of mapping is described in 
ETS 300 138-1 [21], annexe. 



5.2.9.2 



Actions at the incoming AGCF/VGW 



CUG checks at the destination AppHcation Server and determination of the type of call request in correlation with the 
CUG information received in the Initial INVITE message and the CUG attributes of the called user are described in 
TS 183 054 [28]. The call setup sent to the CUG terminating user does not contain any CUG information. 

5.2.10 User User Service (UUS) 

The coding of the User-user information element is described within ETS 300 286-1 [38]. The User-to-User header is 
defined within draft-johnston- sipping-cc-uui-02.txt [i.l]. 

The content of the uuidata field of the User-to-User header shall start with the first octet being the protocol 
discriminator and followed by the user information octets. 
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The format of the uuidata field shall be the hexadecimal representation of binary data coded in ascii alphanumeric 
characters. For example, the 8- bit binary value 001 1- 1 1 1 1 is 3F in hexadecimal. To code this in ascii, one 8- bit byte 
containing the ascii code for the character '3' (001 1- 001 1 or 033H) and one 8- bit byte containing the ascii code for the 
character 'F' (0100- 01 10 or 046H) are required. For each byte value, the high-order hexadecimal digit is always the first 
digit of the pair of hexadecimal digits. The ascii letters used for the hex digits shall always be capital form. 

EXAMPLE: 

User-to-User:04C81031313232333334343535363637373838FA08303900064630E9E0;encoding=hex. 

Interworking procedures between the User-USer information element and User-to-User header are defined in the 
following clauses. 

5.2.10.1 Actions at the Outgoing AGCF/VGW 



5.2.10.1.1 



Service 1 (UUS1) implicit 



Service 1 may be requested implicitly by the presence of the user-user information element in the SETUP message 
which is mapped into the user-to-user information parameter of the initial INVITE. 

Table 5.2.10.1.1-1: Implicit UUS1 transfer 



DSS 1 messages 


SIP messages 


SETUP ^ 


INVITE ^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 


PROGRESS, ALERTING, CONNECT, DISCONNECT ^ 


18x,200OK, BYE^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 


DISCONNECT, RELEASE, RELEASE COMPLETE ^ 


BYE^ 


User-user information element 

Protocol discriminator and User Information 


User-to-User header 
uuidata 



5.2.1 0.1 .2 Service 1 (UUS1 ) explicit 

Table 5.2.10.1.2-1: Explicit UUS1 invocation 



SETUPS 




Content 




Facility information element 

UserUserService invoke component 
Service 1 preferred 






User-user information element (see note 2) 




Facility information element 

UserUserService invoke component 
Service 1 required 






User-user information element (see note 2) 





A service 1 explicit request preferred or required is rejected as described below. 

Service 1 rejection 

Rejection initiated by the 0-AGCFA^GW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.1.1.2.2/EN 300 286-1 [38]. 



Table 5.2.10.1.2-2 describes the handling of a rejection indication received from the network when the service 1 was 
requested as required. 



Table 5.2.10.1.2-3 describes the handling of a rejection indication received from the network when the service 1 was 
requested as preferred. 
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Table 5.2.10.1.2-2: Service 1 rejection service requested as "required" 



DSS1 messages 


SIP messages 


^DISCONNECT 




Cause information element 
Value 69 (requested facility not implemented 
Facility information element 
UserUserService return error component 
rejectedByNetwork 





Table 5.2.10.1.2-3: UUS1 rejection: service requested as "preferred" 



DSS 1 messages 


SIP messages 


CALL PROCEEDING, ALERTING, PROGRESS, 
CONNECT, DISCONNECT or RELEASE 




Facility information element 

UserUserService return error component 
rejectedByNetwork 


NOTE: UUS return error component shall be sent in next regular message. 



5.2.10.1.3 



Service 2 



Table 5.2.10.1.3-1: UUS2 invocation 



SETUPS 


SIP messages 


Content 




Facility information element 

UserUserService invoke component 
Service 2 preferred 


Facility information element 

UserUserService invoke component 
Service 2 required 



A service 2 is rejected as described below: 

Service 2 rejection 

Rejection initiated by the 0-AGCFA^GW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.2.1.2/ EN 300 286-1 [38]. 

Table 5.2.10.1.3-2 describes the handling of a rejection indication received from the network when the service 2 was 
requested as required. 



Table 5.2.10.1.3-3 describes the handling of a rejection indication received from the network when the service 2 was 
requested as preferred. 

Table 5.2.10.1.3-2: UUS2 rejection: service requested as "required" 



DSS1 messages 


SIP messages 


^DISCONNECT 




Cause information element 
Value 69 (requested facility not implemented) 
Facility information element 
UserUserService return error component 
rejectedByNetwork 
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Table 5.2.10.1.3-3: UUS2 rejection: service requested as "preferred" 



DSS 1 messages 


SIP messages 


^ALERTING, DISCONNECT (see note 1) 




Facility information element 

UserUserService return error component 
rejected By Network 



5.2.10.1.4 



Service 3 



Table 5.2.10.1.4-1: UUS3 invocation 



SETUPS 


SIP messages 


Content 




Facility information element 

UserUserService invoke component 
Service 3 preferred 


Facility information element 

UserUserService invoke component 
Service 3 required 



A service 3 request during call setup is rejected as described below. 

Table 5.2.10.1.4-2: UUS3 activation received from the calling user in active phase 



FACILITY ^ 


SIP messages 


Facility information element 

UserUserService invoke component 
Service 3 preferred 





Service 3 rejection 

Rejection initiated by the 0-AGCFA^GW when it cannot support the service is not relevant to the interworking and is 
described in clause 9.3.1.1.2/EN 300 286-1 [38]. 

Rejection of service 3 requested during call establishment. 



Table 5.2.10.1.4-3 describes the handling of a rejection indication received from the network when the service 3 was 
requested as required. 

Table 5.2.10.1.4-4 describes the handling of a rejection indication received from the network when the service 3 was 
requested as preferred. 

Table 5.2.10.1.4-3: UUS3 rejection: service requested as "required" during call establishment 



DSS1 messages 


SIP messages 


^DISCONNECT 




Cause information element 
Value 69 (requested facility not implemented) 
Facility information element 
UserUserService return error component 
rejectedByNetwork 
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Table 5.2.10.1.4-4: UUS3 rejection: service requested 
as "preferred" during call establishment 



DSS 1 messages 


SIP messages 


^CONNECT, DISCONNECT 




Facility information element 
UserUserService return error component 
reJectedByNetwork 



Rejection of service 3 requested after call establishment 

Rejection of service 3 requested after call establishment is not relevant to the interworking and is described in 
clause 9.3.1.2.2/EN 300 286-1 [38]. 

Table 5.2.10.1.4-5: Rejection of UUS3 requested by the calling user after call establishment 



DSS 1 messages 


SIP messages 


^FACILITY 




Facility information element 

UserUserService return error component 
reJectedByNetwork 



5.2.10.2 Actions at the incoming AGCF/VGW 



5.2.10.2.1 



Service 1 (UUS1) implicit 



Service 1 may be requested implicitly by the presence of the User-to-User header field of the Initial INVITE which is 
mapped into the user-user information element in the SETUP message. 



If service 1 is requested: 



Table 5.2.10.2.1-1: Implicit UUS1 transfer 



SIP messages 


DSS 1 messages 


INVITE ^ 


SETUP ^ 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


18x, 200OK, BYE 
(see note) 


ALERTING, CONNECT, DISCONNECT, RELEASE, 
RELEASE COMPLETE 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


BYE 


DISCONNECT 


User-to-User header 
uuidata 


User-user information element 

Protocol discriminator and User Information 


NOTE: The correspondences between SIP and DSS 1 messages are described in clause 5.1 .1 . 



If there is no user-user information element in the SETUP message, the Application Server shall discard the User-to- 
User header field possibly received afterwards from the user or from the SIP side. 

5.2.11 Call Waiting (CW) 

5.2.1 1 .1 Actions at the Outgoing AGCF/VGW 

No action required at the outgoing AGCF/VGW. Basic call procedures apply. 
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5.2.1 1 .2 Actions at the incoming AGCF/VGW 

5.2.1 1 .2.1 Procedure at coincident S and T reference point 

If B-Channel busy is detected, AGCFA^GW should reject the call with 486 (Busy Here). 

Table 5.2.1 1 .2.1-1 : Sending of CW notification 



^180 


^ALERTING 





5.2.1 1 .2.2 Notification received at T reference point 

A CW notification may be received at T reference point in the ALERTING message. 

Table 5.2.1 1 .2.2-1 : Receipt of a CW notification from a private network 



^18x 
(see note) 


^ALERTING/PROGRESS/NOTIFY 




Notification indicator 
information element 




Notification description 


No mapping 


110 0000 

Call is a waiting call 


NOTE: In case of receipt of ALERTING or PROGRESS, 180 or 183 is sent as described in clause 5.1 .2.2. In 
case of receipt of NOTIFY, 183 is sent. 



5.2.12 Terminal Portability (TP) 

5.2.12.1 Actions at the outgoing AGCF/VGW 

5.2.12.1 .1 Invocation at coincident S and T reference point 

Table 5.2.12.1.1-1 : TP invocation 



IVIessage received from the DSS 1 -^ 


INVITE / UPDATE^ 


SUSPEND 


SDP: a=sendonly 


RESUME 


SDR: a=sendrecv 



The action taken on the access side upon receipt of SUSPEND and RESUME messages are described in 5.6/Q.931 [54] 
and figure A.6/Q.931 [54]. 

Upon the T307 expiry, a Release message (BYE or CANCEL) is sent with the cause value No. 102, recovery on timer 
expiry. No action is taken on the DSS 1 side. 

5.2.12.1 .2 Notification received at T reference point 

A TP notification may be received at T reference point from a point-to-point data link in the active phase of the call. 
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Table 5.2.12.1.2-1 : Receipt of a TP notification from a private network 



NOTIFY^ 


INVITE/UPDATE ^ 


Notification indicator 
information element 




Notification description 




000 0000 
User suspended 


SDP: a=sendonly 


000 0001 
User resumed 


SDP: a=sendrecv 



5.2.12.2. Actions at the incoming AGCF/VGW 

5.2.12.2.1 Invocation at coincident S and T reference point 

Table 5.2.12.2.1-1 : TP invocation 



^ INVITE /UPDATE 


Message received from the DBS 1 


SDP: a=sendonly 


SUSPEND 


SDP: a=sendrecv 


RESUME 



The actions taken on the access side upon receipt of the SUSPEND and RESUME messages are described in 
5.2.6/Q.931 [54] and figure A.6/Q.931 [54]. 

5.2.12.2.2 Notification received at T reference point 

A TP notification may be received at T reference point in the active phase of the call. 

Table 5.2.12.2.2-1 : Receipt of a TP notification from a private network 



^INVITE /UPDATE 


^NOTIFY 




Notification indicator 
information element 




Notification description 


SDP: a=sendonly 


000 0000 
User suspended 


SDP: a=sendrecv 


000 0001 
User resumed 



5.2.13 Three-party (3PTY) 

Based on local policy, the AGCF may subscribe for the conference event package on behalf of the ISDN participant 
after he is added to a three party. 

When the conference event package option is implemented, and one of the following events occurs at the AGCFA^GW: 

• A 200 OK is received as a response to an initial INVITE request originated by the AGCF/VGW, where the 
Contact header field contains an "isfocus" parameter; or 

• An ACK message is received which acknowledges a 200 OK response to the initial INVITE request, and the 
initial INVITE request is originated by the conferencing AS and contains an "isfocus" parameter in the Contact 
header field. 
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Then the following steps shall be performed: 

1) A SUBSCRIBE request shall be created according to RFC 4575 [44]. 

2) The request URI is set to the Contact address of the conferencing AS. 

3) The P-Asserted-Identity header field, the From header field and the Privacy header field are set with the same 
value as: 

the P-Asserted-Identity header field, the From header field and the Privacy header field in the initial 
INVITE request originated by the AGCFF/VGW; or 

the P-Asserted-Identity header field, the To header field and the Privacy header field in a Ixx or 2xx 
response sent by the AGCFA^GW to the initial INVITE request from the conferencing AS. 

When a full type of notification is received a check is made of the content. If the changes with respect a previous 
version of the notification have not been sent on to the ISDN user for this session, the AGCFVGW shall do a DSSl 
interaction towards the ISDN user. If the changes with respect a previous version of the notification have been sent to 
the ISDN user for this session, the AGCFA^GW shall not do an DSSl interaction towards the ISDN user. 

When a partial notification is received then it is assumed that a value of a received notification has changed, so the 
AGCF/VGW shall do an DSSl interaction towards the ISDN user. 

5.2.13.1 Notification received from the network 

Table 5.2.13.1-1 : 3PTY notification 



^NOTIFY 


^ INVITE 


Notification indicator 
information element 


<conference-info> 


Notification description 


<conference-state> 


100 0010 
Conference established 


<active>true< active/> 


100 0011 
Conference disconnected 


<active>false< active/> 


111 1001 
Remote hold 


SDP a=sendonly 



5.2.13.2 Invocation at coincident S and T reference point 

Before a three way conversation can be estabUshed, one of two existing sessions is set on hold by sending a relNVITE 
with an a attribute set to sendonly in the SDP. To invoke a three party communication after receipt of the BeginSPTY 
invoke component, the AGCFA^GW shall send a an INVITE request with the conference factory URI for the three-way 
session towards the conference focus as described in TS 183 005 [9]. It is assumed, that based on an initial filter 
criterion, the conference AS is involved in the SIP signalling chain. It is assumed, that the conference application server 
is responsible for the notification "conference-established" etc. The previous basic call sessions are not released. 
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Option A: 3PTY invoke by sending a REFER request to each participant. 

Table 5.2.13.2-1 : Three-party (3PTY) invoke using the REFER request 



Procedure 


IVIessage received from served 


IVIessages sent to the Conference AS or remote 




user 


user 




-^ 


-^ 




FACILITY^ 


INVITE Request URI: <userCactive@domain.com> 




Facility IE 


SDP: a=sendonly 


Beginning the 3PTY 


Begin3PTY-lnv 






Call reference IE 


INVITE Request URI: conference factory URI 




Call reference of call A-B 


REFER Request URI: conference factory URI 
Refer-to: <userBonHold@domain.com> 
Method=invite 

REFER Request URI: conference factory URI 
Refer-to: <userCactive@domain.com> 
Method=invite 



Option B: 3PTY invoke by sending an INVITE request with the conference factory URI for the three-way session 
towards the conference focus including the participant list containing the two 3PTY participants. 

Table 5.2.13.2-2: Three-party (3PTY) invoke using the participant list in an INVITE request 



Procedure 


Message received from served 
user 


Messages sent to the Conference AS or remote user 


Beginning the 3PTY 


FACILITY^ 
Facility IE 

Begin3PTY-lnv 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: <userCactive@domain.com> 
SDP: a=sendonly 

INVITE Request URI: conference factory URI 

To:CONFAS 

From: userA@domain.com 

Require: recipient-list-invite 

<?xml version="1.0" encoding="UTF-8"?> 
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" 
xmlns:cp="urn:ietf:params:xml:ns:copyContror'> 
<list> 

<entry uri="userBonHold@domain.com?Call-ID=1 a& 
From=userA@domain.com%3Btag%3Da&To=B%3Btag%3Db" 
cp:copyControl="to7> 

<entry uri=userCactive@domain.com?Call-ID=2a& 
From=userA@domain.com%3Btag%3Da&To=C%3Btag%3Dc 
cp:copyControl="to7> 
</list> 
</resource-lists> 
> 
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Table 5.2.13.2-3: Three-party (3PTY) invoke 



Procedure 


IVIessage received from 
served user 


IVIessages sent to the Conference AS or remote user 


End of three party 

Creation of a private 

communication 

withB 

Creation of a private 

communication 

withC 

Disconnect the 
remote user B 

Disconnect the 
remote user C 


FACILITY-^ 
Facility IE 

End3PTY-lnv 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
SDP: a=sendonly (see note) 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv (see note) 

BYE Request URI: conference factory URI 


HOLD-> 

Call reference IE 

Call reference of call A-C 


INVITE Request URI: <userCactive@domain.com> 
SDP : a=sendonly 


RETRIEVE-^ 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv 


FACILITY-^ 
Facility IE 

EndSPTY-lnv 
Call reference IE 

Call reference of call A-C 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendonly 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP : a=sendrecv 

BYE Request URI: conference factory URI 


DISCONNECT^ 
Call reference IE 

Call reference of call A-B 


BYE Request URI: < userBonHold@domain.com> 

INVITE Request URI: <userCactive@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP : a=sendrecv 

BYE Request URI: conference factory URI 


DISCONNECT^ 
Call reference IE 

Call reference of call A-C 


BYE Request URI: userCactive@domain.com 

INVITE Request URI: < userBonHold@domain.com> 
SDP: a=sendonly 

BYE Request URI: conference factory URI 


RETRIEVE-> 
Call reference IE 

Call reference of call A-B 


INVITE Request URI: < userBonHold@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv 


NOTE: The a line attribi 


Jte depends on the Call referenc 


e of the Facility with the EndSPTY-lnv component 



Table 5.2.13.2-4 describes the actions taken when user B or user C disconnects. 
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Table 5.2.13.2-4: user B or user C disconnects 



Messages sent to or 

received from 

served user 


Call A-B: Active-held connection 

messages sent to B/AS or received from 

B 


Call A-C: Active-idle connection 

message sent to C/AS or received 

from C 


^DISCONNECT 
Call reference IE 

Call reference of call A-B 


^BYE Request URI <userA@domain.com> 


INVITE-> 

Request URI: 

<userCactive@domain.com> 
<conference-info> 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv 

BYE-^ 

Request URI: conference factory URI 


^DISCONNECT 
Call reference IE 

Call reference of call A-C 


INVITE-^ 

Request URI: < userBonHold@domain.com> 
SDP: a=sendonly 

BYE-^ 

Request URI: conference factory URI 


^BYE Request URI 
<userA@domain.com> 


RETRIEVE^ 
Call reference IE 

Call reference of call A-B 


INVITE-> 

Request URI: < userBonHold@domain.com> 
<conference-info> 


Not applicable 


<conference-state> 


<active>false< active/> 


SDP: a=sendrecv 



5.2.13.3 Notification received at T reference point 

Table 5.2.13.3-1 : Receipt of a 3PTY notification from a private network 



NOTIFY^ 


UPDATE/INVITE ^ 


Notification indicator 
information element 


<conference-info> 


Notification description 


<conference-state> 


100 0010 
Conference established 


<active>true< active/> 


100 0011 
Conference disconnected 


<active>false< active/> 


111 1001 
Remote hold 


SDP a=sendonly 



5.2.13.4 Notification received at T reference point 

Table 5.2.13.4-1 : Receipt of a 3PTY notification from a private network 



^ INVITE/UPDATE 


^NOTIFY 


<conference-info> 


Notification indicator 
information element 


<conference-state> 


Notification description 


<active>true< active/> 


100 0010 
Conference established 


<active>false< active/> 


100 0011 
Conference disconnected 


SDP a=sendonly 


111 1001 
Remote liold 
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5.2. 1 4 Completion of Call to Busy Subscriber (CCBS) 

5.2.14.1 Actions at the outgoing AGCF/VGW 

To be completed. 

5.2.14.2 Actions at the incoming AGCF/VGW 

To be completed. 

5.2.15 Completion of Calls on No Reply (CCNR); 

5.2.15.1 Actions at the outgoing AGCF/VGW 

Have to be completed. 

5.2.1 5.2 Actions at the incoming AGCF/VGW 

Have to be completed. 

5.2.16 Advice Of Charge AOC 

As described in [31], three AOC supplementary services exist: 

a) Charging information at communication set-up time (AOC-S) 

The AOC-S service enables a user to receive information about the charging rates at communication 
set-uptime and also to receive further information during the communication if there is a change of charging 
rates. 

b) Charging information during the communication (AOC-D) 

The AOC-D service enables a user to receive information on the recorded charges for a communication during 
the active phase of the communication. 

c) Charging information at the end of the communication (AOC-E) 

The AOC-E service enables a user to receive information on the recorded charges for a communication when 
the communication is terminated. 

5.2.16.1 Actions at the outgoing AGCF/VGW 

Transfer of AOC-S charging information 

The AOC-S charging information is transported during the call establishment, during the call (change in rates). 

During the call establishment, the AOC-S information shall be carried in SIP Ixx provisional response or a 200 OK 
response to an INVITE message, in a MIME body type "application/vnd.etsi.aoc+xml" defined in 
TS 183 047 [31]. 

It's mapped to a FaciHty information element in a DSSl ALERTING, CALL PROCEEDING, PROGRESS, or 
CONNECT message. 

During the call, the AOC-S information shall be carried in a SIP INFO message in a MIME body type 
"application/vnd.etsi.aoc+xml" defined in TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl FACILITY message. 
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Table 5.2.16.1-1: Transport of AOC-S 



SIP messages -^ 
Ixx, 200 OK (INVITE), INFO 


DSS1 messages -^ 
ALERTING, CALL PROCEEDING, 
PROGRESS, CONNECT, FACILITY 


MIME body type "application/vnd.etsi.aoc+xml" 

aoc 
aoc-s 


Facility Information Element 

ChargingRequest 

charginglnformationAtCallSetup 



NOTE: The feature "the served user is the terminating user" doesn't exist for the ISDN, because of this mapping 
from the INVITE request to a SETUP message is not possible. 

Transfer of AOC-D charging information 

The AOC-D charging information is transported during the call. 

The AOC-D information shall be carried in a SIP INFO message in a MIME body type "application/vnd.etsi.aoc+xml" 
defined in TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl FACILITY message. 

Table 5.2.16.1-2: Transport of AOC-D 



SIP messages -^ 
INFO 


DSSl messages -^ 
FACILITY 


MIME body type "application/vnd.etsi.aoc+xml" 

aoc 
aoc-d 


Facility Information Element 

ChargingRequest 

chargingDuringACall 



Transfer of AOC-E charging information 

The AOC-E charging information is transported during the call clearing. 

The AOC-E information shall be carried in a SIP 200 OK response to a BYE message (if the party that has subscribed 
to the AOC-E service clears the call) or in a SIP BYE message (if the party that has subscribed to the AOC-E service 
receives the release of the call), in a MIME body type "application/vnd.etsi.aoc+xml" defined in TS 183 047 [31]. 

It's mapped to a Facility information element in a DSSl DISCONNECT, RELEASE, RELEASE COMPLETE message. 

Table 5.2.16.1-3: Transport of AOC-E 



SIP messages -^ 
BYE, 200 OK (BYE) 


DSSl messages -^ 

DISCONNECT, RELEASE, RELEASE 

COMPLETE 


MIME body type "application/vnd.etsi.aoc+xmr' 

aoc 
aoc-e 


Facility Information Element 

ChargingRequest 

chargingAtTheEndOfACall 



5.3 DSS1 layer 2 failure 

5.3.1 DSS 1 data link reset and data link failure procedures in the 
outgoing AGCF/VGW 

The data link reset and data link failure procedures are respectively described in 5.2.8.8 and 5.2.8.9/Q.931 [54]. 



ETSI 



75 



ETSI TS 183 036 V2.1.1 (2009-01) 



Table 5.3.1-1 : DSS 1 data link reset and data link failure procedures 



^DISCONNECT 


Trigger event 


BYE/CANCEL^ 


Cause information element 

(see note 2) 


Reason header 


Cause value No. 41 
(temporary failure) 


Data link reset in overlap sending state 


Cause value No. 41 
(temporary failure) 


(see note 1 ) 


Data link failure in another state than active state 


Cause value No. 27 
(destination out of order) 


(see note 1 ) 


Failure of the data link reestablishment procedure 
after a data link failure in active state 


Cause value No. 27 
(destination out of order) 


NOTE 1 : The call is cleared internally. No DISCONNECT message is sent on the access. 
NOTE 2: The location is coded '1010' network beyond interworking point. 



5.3.2 DSS 1 data link reset and data link failure procedures in the 
incoming AGCF/VGW 

The data link reset and data link failure procedures are respectively described in 5.8.8 and 5.8.9/Q.931 [54]. 
Table 5.3.2-1 : DSS 1 Data link reset and Data link failure procedures 



^ BYE/4XX/5XX 


Trigger event 


DISCONNECT^ 


Reason header 




Cause information element 

(see note 2) 


cause No. 41 
(temporary failure) 


Data link reset 

in overlap receiving state 


Cause value No. 41 
(temporary failure) 


cause No. 27 
(destination out of order) 


Data link failure 

in another state than active state 


(see note 1 ) 


cause No. 27 
(destination out of order) 


Failure of the data link reestablishment procedure 
after a data link failure in active state 


(see note 1 ) 


NOTE 1 : The call is cleared internally. No DISCONNECT message is sent on the access. 
NOTE 2: The location is coded '1010' network beyond interworking point. 



5.3.3 Release by the outgoing AGCF/VGW 

Table 5.3.3-1 : Release from the originating AGCF/VGW 



^DISCONNECT 


Trigger event 


BYE/CANCEL^ 


Cause information element 

(see note 3) 


Reason header 


Cause value No. 28 

Invalid number format (address 

incomplete) 


Determination that the called number information 
received is incomplete, after an lAM message has 
already been sent 


Cause value No. 28 

Invalid number format (address 

incomplete) 


Same cause value as in the 
REL message 
(see note 1 ) 


Other cases of failure on the SIP side 


Cause value coded 
according to [4] 


Cause value coded 
according to [6] 


Other cases of failure on the DSS 1 side 


Same cause value as in the 
DISCONNECT message 
(see note 2) 


NOTE 1 : If the cause value sent in the BYE/CANCEL message is unknown in DSS 1 , the unspecified cause value of 

the class is sent. 
NOTE 2: If the cause value sent in the DISCONNECT message is unknown in SIP, the unspecified cause value of the 

class is sent. 
NOTE 3: The location is coded '1010' network beyond interworking point. 
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5.3.4 Release by the AGCF/VGW 



Table 5.3.4-1 : Release from the terminating AGCF/VGW 



^Message sent to the SIP 


Trigger event 


Message sent to the DSS 1 -^ (see note 3) 


Point-to-point data link 


Broadcast data link 


480 

Cause value No. 18 

No user responding 


No response to the 
SETUP message 
(T303 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


No action 


480 

Cause value No. 18 

No user responding 


No ALERTING, CONNECT 
or DISCONNECT after 
CALL PROCEEDING 
(T3 10 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


RELEASE 

Cause value No. 102 

Recovery on timer expiry 


480 

Cause value No. 19 

No answer from user (user 

alerted) 


No CONNECT or 
DISCONNECT after 
ALERTING 
(T301 expiry) 


DISCONNECT 
Cause value No. 102 
Recovery on timer expiry 


RELEASE 

Cause value No. 102 

Recovery on timer expiry 


480 

Cause value No. 31 

Nornfiai, unspecified 


Unsuccessful termination of 
the B-channel selection 
procedure 


RELEASE 

Cause 6 

Cliannei unacceptabie 


500 

Cause value coded 

according to [4] 


Other cases of failure on the 
SIP side 


DISCONNECT 

Same cause value as in the 

REL message 

(see note 1 ) 


500 

Same cause value as in the 
DISCONNECT message 
(see note 2) 


other cases of failure on the 
DSS 1 side 


DISCONNECT 
Cause value coded 
according to [6] 


NOTE 1 : If the cause value sent in the 480/500 message is unknown in DSS 1 , the unspecified cause value of the 

class is sent. 
NOTE 2: If the cause value sent in the DISCONNECT message is unknown in SIP, the unspecified cause value of the 

class is sent. 
NOTE 3: The location is coded '1010' network beyond interworking point 



5.4 Service operation 

5.4.1 Call related service operation 

5.4.1 .1 Malicious Call Identification (MCID) 

The invocation of Malicious Call Identification is described in clause 5.2.6. 

When a 200 OK INVITE is received as the final response to the relNVITE containing the MCID request, a 
mCIDRequest return result component is sent to the served user equipment. 

If an unsuccessful final response is received, a mCIDRequest return error component error code "not Available" is 

sent the user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [20]. 

5.4.1 .2 Explicit CoiTiiTiunication Transfer (ECT) 

The mapping of Explicit Communication Transfer related Facility components is described in clause 5.2.7. 

When a 202 Accepted is received, and the NOTIFY message/sipfrag part for both communications indicates the 
successful communication between Transfer target and Transferee, an eCTExecute return result component is sent to 
the served user equipment in the DISCONNECT messages. 
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If an unsuccessful final response was received upon the REFER was sent, an eCTExecute return error component 
value "not Available" is sent to the served user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [35]. 

5.4.1 .3 Closed User Group (CUG) 

The mapping of the CUG request and the handling of unsuccessful final responses is described in clause 5.2.9. 

5.4.1 .4 Three Party Service (3PTY) 

The mapping of Three Party Service related Facility components is described in clause 5.2.13. 

When for the INVITE sent to the conference focus to get a "conference URI" the 200 OK is received and the 202 
Accepted for both REFER sent to the remote participants is received, a Begin3PTY return result component is sent to 
the served user equipment. 

If an unsuccessful final response was received upon the INVITE to get the "conference URI" was sent, a Begin3PTY 
return error component value "not Available" is sent to the served user equipment. 

If an unsuccessful final response was received upon the REFER to establish the conference was sent, a Begin3PTY 
return error component value "not Available" is sent to the served user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

The coding of the FACILITY message and the Facility I.E is described in [24]. 

5.4.1 .5 Completion of Call to Busy Subscriber (CCBS) 

FFS 

5.4.1 .6 Completion of Calls on No Reply (CCNR) 

FFS 

5.4.2 Call independent service configuration 

Call independent service can be achieved using either the Gm reference point or the Ut reference point. In case of the 
Gm reference point the MESSAGE method is used to convey the service related information to the relevant target. In 
general the information to configure a service is embedded in a XML instance document contained in the MESSAGE 
request. In the case of the Ut reference point, HTTP PUT, HTTP GET or HTTP DELETE requests are used in 
accordance with RFC 4825 [48] and the supplementary services application usage specified in TS 183 023 [49]. 

The following clauses specify the mapping between the ROSE components embedded in DSS.l FACILITY messages 
and the XML document to be created. 

5.4.2.1 Communication Diversion Services (CDIV) 

5.4.2.1 .1 Communication Diversion activation 

On receipt of a DSSl FACILITY message containing the ActivationDiversion invoke component, a SIP MESSAGE 
request or a HTTP request is sent that contains a XML "communication-diversion" instance to the Application Server. 
The attribute of the communication-diversion element is "true". The mapping of the Facility I.E is described below. 
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Table 5.4.2.1.1-1: Mapping of conditions. 



FACILITY ^ 


MESSAGE or HTTP PUT Request ^ 


ActivationDiversion invoke 


<communication-diversion active="true" 


Procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1 ) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 

<cp:conditions> 

<media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted- 
Identity header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 196-1 [25]. The string value shall be set to ASN1 
enumerated numeric value of BasicService type in EN 300 196-1 [25] clause D.6. Activation of call 
forwarding for all basic services is achieved by omitting the <media> condition. 

NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the 
P-Asserted-ldentity header by an AGCF. 

NOTE 4: Mapping of the ISDN value "allNumbers" requires further study 



Table 5.4.2.1.1-2: Mapping of actions. 



FACILITY ^ 


MESSAGE or HTTP PUT Request ^ 


ActivationDiversion invoke 


<communication-diversion active="true" 


forwardedToAddress 


Public number 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 
<ss:target> 


userC@domain 


noReplyTimer 


int 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 

<ss:NoReplyTimer> 


20 



On receipt of a 200 OK MESSAGE or HTTP response, a DSSl FACILITY message including the ActivationDiversion 
return result component is sent to the DSSl user equipment. 

If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
communication-diversion instance, a DSSl FACILITY message including the ActivationDiversion return error 
component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 



5.4.2.1.2 



Communication Diversion deactivation 



On receipt of a DSSl FACILITY message containing the DeactivationDiversion invoke component, a SIP MESSAGE 
request or a HTTP Request is sent that contains a XML "communication-diversion" instance to the Application 
Server. The attribute of the communication-diversion element is "false". The mapping of the Facility I.E is described 
below. 
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Table 5.4.2.1.2-1 : Mapping of conditions. 



FACILITY ^ 


MESSAGE or HTTP PUT Request ^ 


DeactivationDiversion invoke 


<communication-diversion active="false" 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(NOTED 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 

<cp:conditions> 

<media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 196-1 [25]. The string value shall be set to ASN1 enumerated 

numeric value of BasicService type in EN 300 196-1 [25] clause D.6. Deactivation of call forwarding for all 

basic services is achieved by omitting the <media> condition. 
NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted-ldentity 

header by an AGCF. 
NOTE 4: Mapping of the ISDN value "allNumbers" requires further study 



On receipt of a 200 OK MESSAGE or HTTP successful response, a DSSl FACILITY message including the 
DeactivationDiversion return result component is sent to the DSSl user equipment. 

If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
communication-diversion instance, a DSSl FACILITY message including the DeactivationDiversion return error 
component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 



5.4.2.1.3 



Communication Diversion interrogation 



On receipt of a DSSl FACILITY message containing the InterrogationDiversion invoke component, a SIP 
MESSAGE or HTTP request is sent that contains a XML "communication-diversion" instance to the Application 
Server. The mapping of the Facility I.E is described below. 

Table 5.4.2.1.3-1: Mapping of. InterrogationDiversion invoke 



FACILITY ^ 


MESSAGE request or HTTP GET request -^ 


InterrogationDiversion invoke 


<communication-diversion> 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1 ) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 
<ss:media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 3 and 4) 




NOTE 1 : In case unconditional call forwarding no corresponding <cp:condition> element is included. 

NOTE 2: The list of basic services is contained in EN 300 196-1 [25]. The string value shall be set to ASN1 enumerated 

numeric value of BasicService type in EN 300 196-1 [25] clause D.6 Interrogation of call forwarding for all basic 

services is achieved by omitting the <media> condition. 
NOTE 3: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted-ldentity 

header by an AGCF. 
NOTE 4: Mapping of the ISDN value "allNumbers" requires further study. 
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On receipt of a MESSAGE request or HTTP successful response that contains a "communication-diversion" XML 
instance, a DSSl FACILITY message is sent to the served user equipment. The mapping of the XML instance into the 
FaciHty I.E InterrogationDiversion invoke return result is described below. 

Table 5.4.2.1.3-2: Mapping of InterrogationDiversion result. 



^ FACILITY 


^ MESSAGE request or HTTP GET response 


InterrogationDiversion return result 


<communication-diversion active="true" 


procedure 


cfu 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 


(see note 1 ) 


cfb 


<busy/> 


cfnr 


<no-answer/> 


basicService 


Speech 
audio3k 
64kbit 


<cp:ruleset> 

<cp:rule id="<rule id "> 
<cp:conditions> 
<ss:media> 


(see note 2) 


servedUserNr 


PartyNumber 


P-Preferred-ldentity or P-Asserted-ldentity 
header (see notes 4 and 5) 




forwardedloAddress 


Public number 


<cp:ruleset> 

<cp:rule id="<rule id"> 
<cp:actions> 

<ss:forward-to> 
<ss:target> 


userC@domain (see note 
3) 


NOTE 1 : If the <busy/> and <no-answer/> conditions are absent from the XIVIL document, the "procedure" element is set 

to "cfu". 
NOTE 2: The list of basic services is contained in EN 300 196-1 [25]. The string value shall be set to ASN1 enumerated 

numeric value of BasicService type in EN 300 196-1 [25] annex D.6. If the <media> element is absent, the 

basicService element is set to allServices. 
NOTE 3: If the country code is equal to the country code where the AGCF/VGW is located, the country code is removed 

from the number string and the Type of Number is set to "national number" else the number string is sent 

unchanged and the Type of number is set to "international number" 
NOTE 4: The servedUSerNr is mapped to either the P-Preferred-ldentity header by a VGW or the P-Asserted-ldentity 

header by an AGCF. 
NOTE 5: Mapping of the ISDN value "allNumbers" requires further study 



If an unsuccessful final response is received upon sending a MESSAGE or HTTP Request including a XML 
"communication-diversion" instance, a DSSl FACILITY message including the InterrogationDiversion return 
error component value "not Available" is sent to the DSSl user equipment. 

NOTE: A more accurate mapping between unsuccessful final responses and ISDN operation errors is for further 
study. 

5.4.2.1 .4 Activation Status Notification Diversion 

Mapping of this procedure requires further study. 
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Annex A (normative): 
Keypad Procedures 

A.1 Generic procedure at the AGCF/VGW side 

On receipt of a service code included within a Keypad facility information element included within a SETUP and/or 
INFO Message(s), the AGCF/VGW sends an INVITE request with the following information: 

• A Request-URI structured as follows: 

A user part containing the service code command, excluding the START and FINISH fields. The same 
Syntax is used as for PSTN. This is shown in clause CI. 2. 1.1 in TS 183 043 [42]. 

A domain name which together with the user part provides sufficient information to the S-CSCF to 
forward the INVITE request to the appropriate AS, based on Initial Filter Criteria stored in the user 
profile, e.g. 

"PX SC (SR SI) SX"@ pes-scc.operator.com 

NOTE 1 : If the service code command includes a square "#" symbol, the userinfo portion of the Request-URI shall 
be in the form of a telephone- subscriber. The series of digits that form the service code command shall be 
encoded as a local-number. The phone-context attribute shall be set to a domain name of the PES 
operator, e.g. phonecontext=pes-scc.homedomain.com that is specific enough to enable the application 
server to interpret the commandecode. Setting the phone-context attribute is required for conformance 
purposes with RFC 3966 [47]. PES network entities (e.g. CSCF) ignore this attribute. 

NOTE 2: In cases where Overlap Signalling is used the regarding rules for Overlap are used. The collection of the 
Service Code Information is done within the related Application Server. 

• To Header: Same info as in R-URI. 

• A P-Asserted-Identifier header containing the public user identity of the subscriber issuing the service code 
command. 

• An SDP offer for a voice cal.l. 

NOTE 3: The SDP offer may be used by the Application Server in case an announcement has to be delivered. 

A.2 Generic procedure at the AS side 

The procedures used at the AS Side are the same as for PSTN as described within TS 183 043 [42], clause C. 1.2. 1.3. 
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Annex B (normative): 

SDP mapping for ISDN 7 kHz service and Inter-working 



B.1 Originating Side 



DSS1 VGW / AGCF 


Toward Far End 


=> DSS1 


SIP INVITE SDP- OFFER => 


BC1 =3,1 kHz audio 


CLEARMODE, PCMA or PCMU 


DSS1-VGW 

orDSS1-AGCF 

or MGCF 

or SIP Phone 7 kHz 

or SIP Phone 3,1 kHz 


BC2 = Unrestricted Digital Info with 
tones/announce 



DSS1 VGW / AGCF 


From Far End 


<= DSS1 


SIP SDP- ANSWER <= 


BC = Unrestricted Digital Info with 
tones/announce (see note 1) 


CLEARMODE, PCMA or PCMU 


DSS1-VGW 

DSS1- AGCF or MGCF 


BC = 3,1 kHz (see note 2) 


PCMA/PCMU 


SIP Phone 
3,1 kHz 



B.2 Terminating side 

a) Case 1 



DSS1 VGW / AGCF (see note 1) 


Far end 


<= DSS1 


SIP INVITE SDP- OFFER<= 


DSS1-VGW 

DSS1-AGCF 

or MGCF 


BC1=3,1 kHz audio 

BC2 = Unrestricted Digital Info with 

tones/announce 


CLEARMODE, PCMA or PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC2 = Unrestricted Digital Info with 
tones/announce 


CLEARMODE, PCMA or PCMU 



b) Case 2 



DSS1 VGW / AGCF (see note 2) 


Far end 


<=DSS1 


SIP INVITE SDP- OFFER <= 


SIP Phone 7 kHz 


BC = 3,1 kHz 


G.722, PCMA, PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC = 3,1 kHz 


PCMA/PCMU 





c) Case 3 



DSS1 VGW / AGCF (see note 2) 


Far end 


<=DSS1 


SIP INVITE SDP- OFFER<= 


SIP Phone 3,1 kHz 


BC = 3,1 kHz 


PCMA, PCMU 


=>DSS1 


SIP INVITE SDP- ANSWER=> 


BC = 3,1 kHz 


PCMA/PCMU 



NOTE 1: VGW/ AGCF Media handling = H.221 structure is carried transparent from end to end. 
NOTE 2: VGW/ AGCF media handling = PCMA/PCMU is carried transparent. 
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Annex C (normative): 
Timers 



This annex specifies the use of the different ISUP, SIP and ISDN timers. 



0-MGCF 



I AM (797) 



INVITE(797) 



y Tisup10(4-6sec) 
$AM(1) 



Tisup1 0(4-6 sec) 
SAM(1) 
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Tisup10(4-6sec) 



Ti/w2 (4-14 sec) J 



ACM(BCi: no indication) 



"^ 



l/S-CSCF 



484 (Min-Length=5) 



ACK 



INVITE(797 11) 



INVITE(797 11 13 12) 



484 



ACK 



183 Session Progress 



X-CSCF 



INVITE(797 11) 



INVITE(797 11 1312) 



484 
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183 Session Progress 



AGCFA/GW 
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INVITE(797 11 1312) 



484 



ACK 



183 Session Progress 



Figure C.1 
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SETUP ACK 



V Tisdn304 
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7 
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3 



1 



AGCFA/GW 



SETUP 



SETUP ACK '^MEICSoll 



"TisDN 302 
INFO 



y Tisdn302 
INFO 



INFO 



TisDN 302 



CALL PROCEEDING 



X-CSCF 



»fWITE(CSq1) 
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l/S-CSCF 



INVITE(CSq2) ■ 
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ACK 
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Figure C.2 
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Figure C.3: Overlap witli Tmfo Timer 
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Table C.1 : SIP - Timer in the network side 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the subsequent 
expiry 


Tinfo 


0,5 s to 2 s 


Overlap sending 


SETUP Received 


Timer expired 


INVITE with the 
collected digits 
received in the 
SETUP and INFOs 




TisdnS 


12 s to 17 s (default 
of 12 s) 


Overlap sending 


On receipt of 404 
Not Found or 484 
Address 

Incomplete on the 
latest INVITE 
transactions for the 
corresponding call. 


Subsequent INFO is 
received, on 
reception of 180 
Ringing, or 183 
Session Progress or 
200 OK (INVITE). 


Release call 




"•"tiri 


0,1 sto2s 
(default 0,1 s) 


Session answering 


On receipt of 200 
OK INVITE 
including the 
option tag "from- 
change", no 
privacy header or 
privacy value 
none, and Userinfo 
of P-Asserted- 
Identity in the 
format of a tel URI. 


At the receipt of an 
UPDATE 


map the received 
200 OK INVITE to 
a CONNECT 
message 
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Table C.2: ISDN Timers in the AGCF/VGW side- overview (Note: the table notes are copied from Q.931) 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the second 
expiry 


Cross-reference 


TS01 


Minimum S min 


Call received 


ALERT received 


CONNECT received 


Clear call 


Timer is not 
restarted 


(see note 2) 


TS02 


10sto1Ss 
(see note S) 


Overlap sending 


SETUP ACK sent 
Receipt of INFO, 
restarts TS02 


With sending 
complete indication, 
or network alert, or 
connect request 
received 


Clear if call 
information 
determined to be 
definitely 
incomplete; else 
send CALL PROC 


Timer is not 
restarted 


Mandatory 


TSOS 


4s 

(see note 1 ) 


Call present 


SETUP sent 


ALERT, CONNECT 
CALL PROC or 
SETUP ACK 
received, REL 
COMPLETE 
received if SETUP 
sent on point-point 
data link 


Retransmit SETUP; 
restart TSOS. If REL 
COMPLETE has 
been received, 
clear the call 


Clear network 
connection. Enter 
call abort state 


Mandatory 


TS04 


20 s 

(provisional value) 


Overlap receiving 


SETUP ACK 
received. Sending 
of INFO restarts 
TS04 


Send INFO; receive 
CALL PROC, ALERT 
or CONNECT 


Clear the call 


Timer is not 
restarted 


Mandatory only if 
S.2.4 implemented 


N0TE1 

NOTE 2 

NOTES 
NOTE 4 
NOTES 
NOTE 6 
NOTE? 

NOTES 
NOTE 9 
N0TE1 


This default value assumes the use of default values at layer 2, i.e. [N200 + 1] times T200. Whether these values should be modified when layer 2 default 
values are modified by an automatic negotiation procedure is for further study. 

The network may already have applied an internal alerting supervision timing function, e.g. incorporated within call control. If such a function is known to be 
operating on the call, then timer TS01 is not used. 

The value of this timer is implementation dependent but should be less than the value of TS16 (the note is not used in the present document). 
If in the call abort state, the call reference is released. Otherwise, no action is taken on expiry of timer TS12 (the note is not used in the present document). 
The value of timer TS02 may vary beyond these limits, e.g. as a result of called party number analysis. 
The value of this timer TS06 is network dependent (the note is not used in the present document). 

The value of timer TS10 may be different in order to take into account the characteristics of a private network (the note is not used in the present 
document). 

This value may vary by network-user agreement (the note is not used in the present document). 

The restart procedures contained in S.S may be used on B-channels in the maintenance condition (the note is not used in the present document). 
D: The value of this timer is network dependent (the note is not used in the present document). 



ETSI 



87 



ETSI IS 183 036 V2.1.1 (2009-01) 



Table C.3: Q.931 - ISDN Timers in the user side- overview 



Timer 
number 


Default time-out 
value 


State of call 


Cause for start 


Normal stop 


At the first expiry 


At the second 
expiry 


Cross-reference 


T301 


Minimum 3 min. 


Call Delivered 


ALERT received 


CONNECT received 


Clear call 


Timer is not 
restarted 


Mandatory when 
Annex D is 
implemented (see 
note 3) 


T302 


15s 


Overlap receiving 


SETUP ACK sent 
Restart when INFO 
received 


INFO received with 
sending complete 
indication; or internal 
alerting; or internal 
connection; or a 
determination that 
sufficient information 
has been received 


Clear if call 
information 
determined to be 
incomplete; else 
send CALL PROC 


Timer is not 
restarted 


Mandatory only if 
5.2.4 is 
implemented 


T303 


4s 

(see note 1 ) 


Call Initiated 


SETUP sent 


ALERT (annex D), 
CONNECT 
(Annex D), SETUP 
ACK, CALL PROC or 
REL COMPLETE 
received 


Retransmit SETUP; 
restart T303. If REL 
COMPLETE was 
received, clear the 
call (Annex D) 


Clear internal 
connection. Send 
REL COMPLETE. 
Enter Null state 


Mandatory when 
annex D is 
implemented; 
otherwise optional 


T304 


30 s 


Overlap Sending 


INFO sent 
Restarted when 
INFO sent again 


CALL PROC, 
ALERT, CONNECT, 
DISC or prog. ind. 1 
or 2 received 


DISC sent 


Timer is not 
restarted 


Optional 
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Annex D (normative): 
Overlap Sending 

D.1 multiple INVITE Overlap Dialling Procedures 
(Optional) 

D.1 .1 Actions at the originating VGW/AGCF 

D.1 .1 .1 Terminating overlap signalling at originating VGW/AGCF 

If overlap sending is used, the SETUP message contains either: 

a) no called number information; or 

b) incomplete called number information; or 

c) called number information which the network cannot determine to be complete. 

When the VGW/AGCF has received called number information element from the calling user in a SETUP message 
(possibly followed by INFORMATION messages), it shall send an INVITE request with all the available called number 
information in the Request line and the originating SDP (derived from the BC and optionally present HLC for the VGW 
- else as obtained from the originating AGW (and influenced by the BC and optionally present HLC)) - see 
table 5.1.1.1.4-2. 

The AGCFA^GW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in a sequence of Called party number information elements. Among other purposes, this digit map can 
be used to: 

• Identify the required number of digits to be entered for a particular digit sequence. 

The procedures for digit maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. Even in the absence of a digit 
map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall contain a configurable 
parameter indicating the minimum number of digits expected in the sequence of Called party number information 
elements before a Request-URI is constructed and an INVITE request sent. The minimum number could be zero. 

D.1 .1 .2 Sending of INVITE without determining the end of address signalling 

On receipt of such a SETUP message, the AGCFA^GW starts the ISDN timer T3Q2, sends a SETUP ACKNOWLEDGE 
message to the user and enters the overlap sending state. 

If no number information is included the network will return dial tone, if required by the tone option. 

If the received BC in the SETUP message is coded with speech, 3,1 kHz audio, UDI/TA, it shall include 
progress indicator No. 8, in-band information or appropriate pattern is now available, in the SETUP 
ACKNOWLEDGE message. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the originating VGW/AGCF sends an INVITE request before the end of address 
signalling is determined, the originating VGW/AGCF: 

uses the SIP precondition extension within the INVITE request; 

starts timer Tinfo if not running; and 

is prepared to process further incoming INFO as described below; 

is prepared to handle incoming SIP 404 or 484 error responses as detailed in clause D. 1 . 1 .3. 
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2) On receipt of a new DSSl INFO message, the originating VGW/AGCF shall: 
stop timer TisdnS (if it is running); 
send an INVITE request complying to the following: 

■ The INVITE request uses the SIP preconditions extension. 

■ The INVITE request includes all digits received so far for this call in the Request-URL 

If subsequent address information in a DSSl INFO message is received after the SIP 404 or 484 error 
responses has been received, the INVITE request additionally includes the digits received. 

NOTE: The DSSl timer 302 is restarted with the receipt of a DSSl INFO message. 

At the receipt of a new DSSl INFO message, a SIP 18x provisional response, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF shall stop TisdnS. 

As a network option the Timer T-^^^^ can be used , in this case the following procedure apply starting with the first digit 
received by the AGCF/VGW : 

• start timer T-j^^-^ with receiving the SETUP; 

• collect all digits received within INFO messages. 

• At expiry of timer T- ^^^-^ the initial INVITE is sent out as described under 1 . 

• If further digits are needed then the AGCFA^GW shall collect further digits until min length has been reached. 
As a network Option the first INVITE can be sent with the receipt of the SETUP message and the T-j^^-^ is started. 

The T-j^|-Q shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided to the 
originating user. 

D.1 .1 .3 Special handling of 404 Not Found and 484 Address Incomplete 
responses after sending of INVITE without determining the end of 
address signalling 

This Clause is only applicable when the network option of Sending of INVITE without determining the end of address 
signalling is being used (see clause D.1.1.2). 

On receipt of a 404 Not Found or 484 Address Incomplete response, the originating VGW/AGCF starts timer TisdnS, if 
there are no other pending INVITE transactions for the corresponding call. 

At the receipt of fresh address information, or a SIP 18x provisional responses, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF stops 302 and TisdnS. 

The originating VGW/AGCF shall send a RELEASE message with Cause Value 28 towards the ISDN user if Tisdn3 
expires. 

Option a) Overlap with T-j^^-^ Timer. 
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AGCFA/GW 



SETUP 



^ 




SETUP ACK 






INFO 








INFO 








INFO 








INFO 








INFO 







CALL PROCEEDING 



I- Info 



INVITE Cseq 1 



x-CSCF 



183 Session Progress Cseq 1 



Figure D.I. 1.3-1 : Overlap with Tj^f^ Timer- no transaction is pending 
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AGCFA/GW 
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CALL PROCEEDING 



x-CSCF 



> 



Linfo 



INVITE Cseq 1 



INVITE Cseq 2 



484 Cseq 1 



ACK 



183 Session Progress Cseq 2 



Figure D.1. 1.3-2: Overlap with Tinfo Timer one transaction is pending 
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Option b) Overlap with Digit Map. 
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Figure D.1 .1.3-3: Overlap with digit map 
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Option c) Overlap with Digit Map and T-j^^-^ Timer 
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Figure D.1 .1.3-4: Overlap with digit map and Tinfo timer 
digit map matchied before Tj^fo expiry 
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AGCFA/GW 
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Figure D.1 .1.3-5: Overlap with digit map and Tinfo timer 
digit map matchied after Tjn,o expiry 



ETSI 



95 



ETSI TS 183 036 V2.1.1 (2009-01) 



Option d) 484 message with Min-length X parameter 
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Figure D.1. 1.3-6: Overlap option with 484 message with Min-length x parameter 
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option c) 484 message without Min-length X parameter 
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Figure D.1. 1.3-7: 484 message without Min-lengtii X parameter 

D.1 .2 Actions at tlie terminating VGW/AGGF 

See annex H for DDL For all other no further action is needed. 

D.2 In-Dialog Method (Optional) 

D.2.1 Actions at the originating VGW/AGCF 

D.2.1 .1 Terminating overlap signalling at originating VGW/AGCF 

If overlap sending is used, the SETUP message contains either: 

a) no called number information; or 

b) incomplete called number information; or 

c) called number information which the network cannot determine to be complete. 
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When the VGW/AGCF has received called number information element from the calling user in a SETUP message 
(possibly followed by INFORMATION messages), it shall send an INVITE request with all the available called number 
information in the Request line and the originating SDP (derived from the BC and optionally present HLC for the VGW 
- else as obtained from the originating AGW (and influenced by the BC and optionally present HLC)) - see 
table 5.1.1.1.4-2. 

The AGCFA^GW can contain a configurable digit map which is used to analyse the Called party information element 
contents received in a sequence of Called party number information elements. Among other purposes, this digit map can 
be used to: 

• identify the required number of digits to be entered for a particular digit sequence. The procedures for digit 
maps are described within TS 183 043 [42], clause 7.3.1.3.1.1. 

Even in the absence of a digit map, it is appropriate for the AGCF/VGW to collect dialled digits. The AGCFVGW shall 
contain a configurable parameter indicating the minimum number of digits expected in the sequence of Called party 
number information elements before a Request-URI is constructed and an INVITE request sent. The minimum number 
could be zero. 

D.2.1 .2 Sending of INVITE without determining the end of address signalling 

On receipt of such a SETUP message, the AGCFA^GW starts the ISDN timer T3Q2, sends a SETUP ACKNOWLEDGE 
message to the user and enters the overlap sending state. 

• If no number information is included the network will return dial tone, if required by the tone option. 

• If the received BC in the SETUP message is coded with speech, 3,1 kHz audio, UDI/TA, it shall include 
progress indicator No. 8, in-band information or appropriate pattern is now available, in the SETUP 
ACKNOWLEDGE message. 

1) As a network option, the originating VGW/AGCF may send INVITE requests without determining the end of 
address signalling. If the originating VGW/AGCF sends an INVITE request before the end of address signalling 
is determined, the originating VGW/AGCF: 

use the SIP precondition extension within the INVITE request; 

be prepared to process INFO as described below; 

be prepared to handle incoming SIP 484 (Address Incomplete) responses; 

on receipt of 404 Not Found or 484 Address Incomplete start timer Tisdn3. 

2) On receipt of a new INFO from the DSS 1 side, the AGCF/VGW shall: 

if an early dialog has been established, send a SIP INFO request including the additional digits for this 
call; 

If an early dialog has not been established, wait for a final error response for the previous INVITE and 
send an INVITE request including all digits received so far for this call in the Request-URI. 

At the receipt of a new DSSl INFO message, a SIP 18x provisional response, or a SIP 200 OK (INVITE), the 
originating VGW/AGCF shall stop Tisdn3. 

As a network option the Timer T-j^^-^ can be used , in this case the following procedure apply starting with the first digit 
received by the AGCF/VGW: 

• start timer T-j^^-^ with receiving the SETUP; 

• collect all digits received within INFO messages. 

• At expiry of timer T-j^^-^ the initial INVITE is sent out as described under 1). 

If further digits are needed then the AGCF/VGW shall collect further digits until min length has been 
reached. 
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As a network Option the first INVITE can be sent with the receipt of the SETUP message and the T-j^^-^ is started. 

The timer T-j^^-^ shall not be used if the INVITE has to be sent immediately because e.g. the hotline feature is provided 
to the originating user. 

The originating VGW/AGCF shall send a RELEASE message with Cause Value 28 towards the ISDN user if TisdnS 
expires. 

Option a) Overlap with T-j^^-^ Timer. 
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Figure D.2.1.2-1 : Overlap with Tj^f^ Timer- no transaction is pending 
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Figure D.2.1.2-2: Overlap with Tinfo Timer no transaction is pending 
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Option b) Overlap with Digit Map. 
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Figure D.2.1.2-3: Overlap with digit map 
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Option c) Overlap with Digit Map and T-j^^-^ Timer. 
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Figure D.2.1.2-4: Overlap with digit map and Tinfo timer 
digit map matchied before Tj,^fQ expiry 
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Figure D.2.1.2-5: Overlap with digit map and Tinfo timer 
digit map matchied after Tjn,o expiry 
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Option d) 484 message with Min-length X parameter. 
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Figure D.2.1.2-6: Overlap option witli 484 message witli Min-lengtii x parameter 
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option c) 484 message without Min-length X parameter 
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Figure D.2.1.2-7: 484 message without lUlin-lengtIi X parameter 



D.2.2 Actions at the terminating VGW/AGCF 

See annex H for DDL For all other no further action is needed. 
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Annex E (normative): 
Direct Dialling in 

This annex describes the handhng of Direct Dialling In. 



E.1 Multiple INVITES Method (Optional) 

E.1 .1 Actions at the incoming AGCF/VGW 
E.1 .1 .1 Receipt of Subsequent INVITE messages 

If the SETUP message has already been sent and the SETUP ACKNOWLEDGE message has been received, overlap 
receiving is used, an INFORMATION message will be sent upon receipt of each Subsequent INVITE. 

When the SETUP ACKNOWLEDGE message is received, the AGCFA^GW shall: stop timer T303; start timer T304; 
enter the Overlap receiving state; and send the remainder of the call information (if any) in one or more 
INFORMATION messages, starting timer T304 when each INFORMATION message is sent. 

At the expiration of timer T304 the network initiates call clearing with cause No. 28, invalid number format (address 
incomplete) to the calling user and cause No. 102, "recovery on timers expiry" to the called user. 
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Figure E.1. 1.1-1: Receipt of Subsequent INVITE messages 
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x-CSCF 



AGCFA/GW 
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Figure E.1.1.1-2: Receipt of Subsequent INVITE messages 

Receipt of subsequent INVITE messages 

This clause applies when overlap operation is supported across the AGCF/VGW. If the AGCFA^GW receives an 
INVITE with the same Call-ID and From tag as a previous INVITE which was associated with a DSSl call/bearer 
control instance currently existing on the DSSl side, then: 

a) If the number of digits in the Request-URI is a superset of the number of digits already accumulated for the 
call, the AGCFA^GW shall generate an INFO and pass it to outgoing DSSl procedures. The INFO shall 
contain in its Called party Number parameter only the additional digits received in this Request-URI compared 
with the digits already accumulated for the call. 

b) If the number of digits in the Request-URI is fewer than the number of digits already accumulated for the call, 
then the AGCF/VGW shall immediately send a 484 Address Incomplete response for this INVITE. In this case 
no INFO is sent to DSSl procedures. 



E.2 In-Dialog Method (Optional) 

E.2.1 Actions at the incoming AGCF/VGW 
E.2.1 .1 Receipt of Subsequent INVITE messages 

If the SETUP message has already been sent and the SETUP ACKNOWLEDGE message has been received, overlap 
receiving is used, an INFORMATION message will be sent upon receipt of each SIP INFO request carrying additional 
digits. 

When the SETUP ACKNOWLEDGE message is received, the AGCFA^GW shall: stop timer T303; start timer T304; 
enter the Overlap receiving state; and send the remainder of the call information (if any) in one or more 
INFORMATION messages, starting timer T304 when each INFORMATION message is sent. 
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At the expiration of timer T304 the network initiates call clearing with cause No. 28, invalid number format (address 
incomplete) to the calling user and cause No. 102, "recovery on timers expiry" to the called user. 
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Figure E.2.1.1-1: Receipt of SIP INFO request 
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Figure E.2.1.1-2: Receipt of SIP INFO requests 



Receipt of SIP INFO requests 
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This clause applies when overlap operation is supported across the AGCF/VGW. If the AGCFA^GW receives a SIP 
INFO request within an early dialog created by a previous INVITE, which was associated with a DSSl call/bearer 
control instance currently existing on the DSSl side, then the AGCFA^TW shall generate an INFO and pass it to 
outgoing DSSl procedures. The INFO shall contain in its Called party Number parameter only the additional digits, 
received in the SIP INFO request, compared with the digits already accumulated for the call. 
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Annex F (informative): 

Handling and interworking of DSS1 messages and 

Information Elements 

This annex describes the handhng and interworking of DSSl messages and Information Elements at the AGCFA^GW. 

Table F.1 : DSS1 messages 



DSS1 Message 


Handling in SIP 


ALERTING 


Interworking with 180 Ringing 


CALL PROCEEDING 


Interworking with 183 Session Progress or local 
significance 


CONNECT 


Interworking with 200 OK INVITE 


CONNECT ACKNOWLEDGE 


local significance 


PROGRESS 


Interworking with 183 Session Progress or local 
significance 


SETUP 


Interworking with INVITE 


SETUP ACKNOWLEDGE 


local significance 


RESUME 


Interworking with INVITE or UPDATE containing the P- 
Service-Notification value "user-resumed" 


RESUME ACKNOWLEDGE 


local significance 


RESUME REJECT 




SUSPEND 


Interworking with INVITE or UPDATE containing the P- 
Service-Notification value "user-suspended" 


SUSPEND ACKNOWLEDGE 


local significance 


SUSPEND REJECT 




DISCONNECT 


Interworking with BYE, CANCEL or unsuccessful status 
responses 


RELEASE 


Interworking with BYE, CANCEL or unsuccessful status 
responses 


RELEASE COMPLb It 


Interworking with BYE, CANCEL or unsuccessful status 
responses or local significance 


INFORMATION 


Interworking with INVITE in case of overlap procedure 


NOTIFY 


Interworking with INVITE or UPDATE 


SEGMENT 


No interworking 


STATUS 


local significance 


STATUS ENQUIRY 


local significance 


USER INFORMATION 


No interworking 


CONGESTION CONTROL 


local significance 


RESTART 


local significance 


RESTART ACKNOWLEDGE 


local significance 


HOLD 


Interworking with INVITE or UPDATE. HOLD procedure 
based on TS 183 010 [10] 


HOLD ACKNOWLEDGE 


local significance 


HOLD REJECT 




RETRIEVE 


Interworking with INVITE or UPDATE. HOLD procedure 
based on TS 183 010 [10] 


RETRIEVE ACKNOWLEDGE 


Local significance 


RETRIEVE REJECT 




REGISTER 


Interworking with CCBS or CCNR 


FACILITY 


Operation of the configuration of services or user 
equipment 
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Table F.2: DSS1 Information Elements 



DSS1 Information Element 


Handling in SIP 


Protocol discriminator 


Local significance 


Call reference 


Local significance 


Message type 


Local significance 


Channel identification 


Local significance 


Bearer capability 


Interworking with INVITE, 18x, 200 OK 


High layer compatibility 


Interworking with INVITE 


Low layer compatibility 


Interworking with INVITE 


Progress indicator 


Interworking with INVITE, 18x, 200 OK 


Display 


Interworking with INVITE, 18x, 200 OK CANCEL, BYE 


Date/time 


Local handling 


Signal 




Sending complete 


Indication for end of dialling 


Keypad facility 


Maintenance of services 


Called party number 


Interworking with INVITE 


Calling party number 


Interworking with INVITE 


Calling party subaddress 


Interworking with INVITE 


Called party subaddress 


Interworking with INVITE 


Connected number 


Interworking with 200 OK/UPDATE 


Connected subaddress 


Interworking with 200 OK/UPDATE 


Redirecting number 


Interworking with INVITE 


Redirection number 


Interworking with 181, 180, 200 OK 


Cause 


Interworking with unsuccessful final response, BYE or 
CANCEL 


Notification indicator 


Interworking with INVITE, UPDATE, 18x, 200 OK 


Facility 


Maintenance of services 


Call identity 




Network-specific facilities 


No interworking 


Transit network selection 


No interworking 


Repeat indicator 




Call state 


local 


User-user 


Interworking with INVITE, 18x, 200 OK, BYE 


Information rate 




End-end transit delay 




Transit delay selection and indication 




Packet layer binary parameters 


(X25) 


Packet layer window size 


(X25) 


Packet size 


(X25) 


Closed user group 


No interworking 


Reverse charging indication 


No interworking 


More data 




Restart indicator 


Local significance 


Locking Shift 




Non-locking Shift 
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Annex G (informative): 
Message flows 



G-1 Three party 



Basic call procedure and HOLD 
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established 



Figure G.1-1 : Initial position before starting the 3PTY service. Two sessions, one in hold one active. 
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0-AGCFA/GW 
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Figure G.1-2: Invocation of three party session. Tlie media streams shall be set on hold before 
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0-AGCF/VGW 
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Figure G.1-3: Release the three part conversation to have a 
private communication with the previous active user 
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0-AGCF/VGW 
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Figure G.1-4: Release the three part conversation to have a 
private communication with the previous held user 
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0-AGCFA/GW 
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Figure G.1-5: The served user releases the session with the previous held user 
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Figure G.1-6: The served user releases the session with the previous active user 
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Figure G.1-7: The previous held user disconnects the own session using basic call procedures 
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Figure G.1-8: The previous active user disconnects thie own session using basic call procedures 



G.2 Explicit Communication Transfer (ECT) 

Figures G.2.1 to G.2. 2 describe the message flow in case of interworking of the ECT supplementary service into the 
ECT simulation service. 



ETS\ 



119 



ETSI TS 183 036 V2.1.1 (2009-01) 







0-AGCFA/GW 




AS 




UEB 




UEC 


SETUP (CR1) 




^. 
























ALERTING 


INVITE (CSq1) 


w 








^ 


180 Rinaina 




^ 


^ 


200 OK INVITE 






CONNECT 




^ 


' ACK 














► 












Originating user invokes HOLD 






HOLD (CRD 




w 


INVITE (CSq1,sendonly) 


w 


















^ 


200 OK INVITE (recvonlv) 






' ACK 


w 












W 






SETUP (CR2) 




Originating user establishes a communication with UE C 






^ 


INVITE (CSq2) 




w 








ALERTING 










180 Rinaina 




^ 


^ 
^ 




200 OK INVITE 




^ 


CONNECT 




^ 


ACK 




w 






























w 





Figure G.2-1 : Basic procedure and remote user is set on HOLD 
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Figure G.2-2: Invocation of ECT 
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Annex H (informative): 
Use of progress indicators 



This annex describes the use of the different progress indicator values for non-ISDN and IMS terminals. The Progress 
Indicators for ISDN terminals in the IMS are only applicable for voice connection (speech and 3,1 kHz audio). 

Examples of use are given. 

• Progress indicator No. 1 - Indicates that interworking with a non-ISDN has occurred within the network or 
networks through which the call has traversed. 

• Progress indicator No. 2 - Indicates that the destination user is not ISDN. 

• Progress indicator No. 3 - Indicates that the origination user is not ISDN. 

• The ISDN access indicator (see note) - "originating access ISDN" is transported in the IMS as PSTN XML 
Progresslndicator No. 6. 

• The ISDN access indicator (see note) - ''Terminating access ISDN" is transported in the IMS as PSTN 
XML Progresslndicator No. 7 

NOTE: The "ISDN access indicator" is defined in the ITU-T Recommendation Q.763 [i.2] in the BCI and FCI 
and indicates the access type. The access indicator can be not directly mapped to the ISDN progress 
indicator and is not defined in EN 300 403-1 [29]. The ISDN access indicator can be created only from 
the network e.g. VGW, AGCF, SIP/ISUP MGCF, not from the UE and shall prevent the sending of a 
progress indicator indicating a non-ISDN connection. 

The use of progress indicators Nos. 1, 2 and 3 is exemplified in the following. 

Several interworking situations are identified in figure H-1: 

a) interworking with another network; 

b) interworking with a non-ISDN user connected to ISDN; 

c) interworking with non-ISDN equipment within the calling or called user's premises; 

d) interworking with another network behind the T reference point; 

e) interworking with an IMS network behind the S/T reference point (simulated service); 

f) interworking with an IMS network behind the S/T reference point (simulated /emulated service in the AGCF); 

g) interworking with an IMS network behind the Gm reference point; 

h) interworking with non-ISDN equipment within the calling or called user's premises which is connected to an 
IMS network; 

i) interworking with another network behind the T reference point which is connected to an IMS network. 
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As regards calls from A (ISDN access in an ISDN network) the following applies: 



Case 


Originating Terminal A receives 
PI 


Originating side 

or 
SIP/ ISUP MGCF 
(PI from the BCI) 

^ PI sent 


Terminating side 
^ PSTN XML 
Progresslndicat 
or sent 


Term. Terminal 
sent 


a 


Pl#1 




Pl#1 




b 


PI #2 




PI #2 




c 


PI #2 
location sub-field = private network 






PI #2 


d 


Pl#1 
location sub-field = private network 






Pl#1 


IMS 


e 






PI #7 




f 






PI #7 




Q 


Pl#1 


Pl#1 






h 


PI #2 


PI #2 


PI #7 


Pl#2 


i 


Pl#1 


Pl#1 


PI #7 


Pl#1 



As regards calls towards A the following applies: 



Case 


Orig Terminal 
PI sent 


Originating 
VGW/AGCF 
PSTN XML 
Progresslndicator 
sent 


Originating side 

or 
SIP/ ISUP MGCF 

PI 
sent in the FCI 


Terminating 
Interworking 

function 
(AGCF/VGW) 


Dest. Terminal A 
receives PI 


a 






Pl#1 




Pl#1 


b 






Pl#3 




PI #3 


c 


Pl#3 








PI #3 
location sub-field 
= private 
network 


d 


Pl#1 








Pl#1 
location sub-field 
= private 
network 


IMS 


e 




PI #6 








f 




PI #6 








Q 




PI #6 








h 


Pl#3 


PI #6 






PI #3 


i 


Pl#1 


PI #6 






Pl#1 



As regards calls from C or D (ISDN access in the IMS) the following applies: 



Case 


Originating C or D Terminal 
receives PI 


0-AGCF/VGW 
^ Plsentin18x 


^ PI sent 

Destination 

MGCF 


Term. Terminal 
sent 


a 


Pl#1 








b 


Pl#2 




PI #2 




c 


Pl#2 






PI #2 


d 


Pl#1 






Pl#1 
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Case 


Originating C or D Terminal 
receives PI 


0-AGCF/VGW 
^ PI sent in 18x 


^ PSTN XML 
Progresslndicator 
sent 
Destination 
MGCF 


Term. Terminal 
sent 


e 






PI #7 




f 






PI #7 




Q 


Pl#1 


Pl#1 






h 


PI #2 






Pl#2 


i 


Pl#1 






Pl#1 



As regards calls towards C or D (non - ISDN access in an ISDN network) the following applies: 



Case 


Orig Terminal 
PI sent 


Originating side 

or 
SIP/ ISUP IWF 

PI 
sent in the FCI 


Terminating 
Interworking 

function 
(AGCF/VGW) 


Dest. Terminal 
Cor D 
receives PI 


a 




Pl#1 


Pl#1 


Pl#1 


b 




Pl#3 


Pl#1 


PI #1 and PI #3 


c 


Pl#3 




Pl#1 


PI #1 and PI #3 


d 


Pl#1 




Pl#1 


Pl#1 


e 






Pl#1 


Pl#1 


f 






Pl#1 


Pl#1 


g 






Pl#1 


Pl#1 


h 


Pl#3 




Pl#1 


PI#1andPI#3 


i 


Pl#1 




Pl#1 


Pl#1 
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ISDN 
Tel. 



S/T 




non-ISDN user 



0"" / Non 
V ISDN 



Figure: H-1 
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